diff --git a/deploy-manage/cloud-organization/billing/manage-subscription.md b/deploy-manage/cloud-organization/billing/manage-subscription.md index 45c8717656..1d131bdde2 100644 --- a/deploy-manage/cloud-organization/billing/manage-subscription.md +++ b/deploy-manage/cloud-organization/billing/manage-subscription.md @@ -4,6 +4,7 @@ mapped_urls: - https://www.elastic.co/guide/en/cloud/current/ec-subscription-overview.html - https://www.elastic.co/guide/en/cloud/current/ec-select-subscription-level.html - https://www.elastic.co/guide/en/cloud/current/ec-licensing.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-licensing.html applies_to: deployment: ess: all diff --git a/deploy-manage/cloud-organization/service-status.md b/deploy-manage/cloud-organization/service-status.md index 67c69039f3..a479fe08f7 100644 --- a/deploy-manage/cloud-organization/service-status.md +++ b/deploy-manage/cloud-organization/service-status.md @@ -4,6 +4,9 @@ mapped_urls: - https://www.elastic.co/guide/en/cloud/current/ec_subscribe_to_individual_regionscomponents.html - https://www.elastic.co/guide/en/cloud/current/ec_service_status_api.html - https://www.elastic.co/guide/en/serverless/current/general-serverless-status.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-service-status.html + - https://www.elastic.co/guide/en/cloud-heroku/current/echservice_status_api.html + - https://www.elastic.co/guide/en/cloud-heroku/current/echsubscribe_to_individual_regionscomponents.html applies_to: deployment: ess: all diff --git a/deploy-manage/deploy/elastic-cloud/available-stack-versions.md b/deploy-manage/deploy/elastic-cloud/available-stack-versions.md index b1ff431bd2..089f40ecc0 100644 --- a/deploy-manage/deploy/elastic-cloud/available-stack-versions.md +++ b/deploy-manage/deploy/elastic-cloud/available-stack-versions.md @@ -4,6 +4,7 @@ applies_to: ess: ga mapped_pages: - https://www.elastic.co/guide/en/cloud/current/ec-version-policy.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-version-policy.html --- # Available stack versions [ec-version-policy] diff --git a/deploy-manage/deploy/elastic-cloud/ech-about.md b/deploy-manage/deploy/elastic-cloud/ech-about.md deleted file mode 100644 index 0037572edc..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-about.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-about.html ---- - -# About [ech-about] - -The information in this section covers: - -* [Subscription Levels](ech-licensing.md) -* [Version Policy](ech-version-policy.md) -* [Elasticsearch Add-On for Heroku Hardware](ech-reference-hardware.md) -* [Elasticsearch Add-On for Heroku Regions](ech-reference-regions.md) -* [Service Status](ech-service-status.md) -* [Getting help](ech-get-help.md) -* [Restrictions and known problems](ech-restrictions.md) - diff --git a/deploy-manage/deploy/elastic-cloud/ech-access-kibana.md b/deploy-manage/deploy/elastic-cloud/ech-access-kibana.md deleted file mode 100644 index 76f4415f06..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-access-kibana.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-access-kibana.html ---- - -# Access Kibana [ech-access-kibana] - -Kibana is an open source analytics and visualization platform designed to search, view, and interact with data stored in Elasticsearch indices. The use of Kibana is included with your subscription. - -For new Elasticsearch clusters, we automatically create a Kibana instance for you. - -To access Kibana: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. Under **Applications**, select the Kibana **Launch** link and wait for Kibana to open. - - ::::{note} - Both ports 443 and 9243 can be used to access Kibana. SSO only works with 9243 on older deployments, where you will see an option in the Cloud UI to migrate the default to port 443. In addition, any version upgrade will automatically migrate the default port to 443. - :::: - -4. Log into Kibana. Single sign-on (SSO) is enabled between your Cloud account and the Kibana instance. If you’re logged in already, then Kibana opens without requiring you to log in again. However, if your token has expired, choose from one of these methods to log in: - - * Select **Login with Cloud**. You’ll need to log in with your Cloud account credentials and then you’ll be redirected to Kibana. - * Log in with the `elastic` superuser. The password was provided when you created your cluster or [can be reset](../../users-roles/cluster-or-deployment-auth/built-in-users.md). - * Log in with any users you created in Kibana already. - - -In production systems, you might need to control what Elasticsearch data users can access through Kibana, so you need create credentials that can be used to access the necessary Elasticsearch resources. This means granting read access to the necessary indexes, as well as access to update the `.kibana` index. - -::::{tip} -If your cluster didn’t include a Kibana instance initially, there might not be a Kibana endpoint URL shown, yet. To gain access, all you need to do is [enable Kibana first](access-kibana.md). -:::: - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-api-console.md b/deploy-manage/deploy/elastic-cloud/ech-api-console.md deleted file mode 100644 index c0aae31830..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-api-console.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-api-console.html ---- - -# Access the Elasticsearch API console [ech-api-console] - -Interact with a specific Elasticsearch cluster directly from the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) without having to authenticate again. This RESTful API access is limited to the specific cluster and works only for Elasticsearch API calls. - -::::{note} -API console is intended for admin purposes. Avoid running normal workload like indexing or search request. -:::: - - -You are unable to make Elasticsearch Add-On for Heroku platform changes from the Elasticsearch API. - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. From the Elasticsearch menu, go to the **API Console** page. -4. Make a selection from the operation drop-down list and complete the path. - - For example, select `GET`, then use the `_cluster/health?pretty=true` path for cluster status and other pertinent details. - -5. If needed, add the body information. - - ::::{tip} - To display the body area, select PUT, POST, or DELETE from the drop-down list. - :::: - -6. Select **Submit**. - -The results of the API operation are displayed, along with the time it took to complete the operation. - -To learn more about what kinds of Elasticsearch API calls you can make from the Cloud UI, check the [Elasticsearch Reference](https://www.elastic.co/guide/en/elasticsearch/reference/current). - diff --git a/deploy-manage/deploy/elastic-cloud/ech-aws-instance-configuration.md b/deploy-manage/deploy/elastic-cloud/ech-aws-instance-configuration.md deleted file mode 100644 index 0b22cdbd74..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-aws-instance-configuration.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-aws-instance-configuration.html ---- - -# Elasticsearch Add-On for Heroku AWS instance configurations [ech-aws-instance-configuration] - -Amazon EC2 (AWS) C6gd, M6gd & R6gd instances, powered by AWS Graviton2, are now available for Elastic Cloud deployments. C6gd, M6gd & R6gd VMs use the [Graviton2, ARM neoverse N1 cores](https://aws.amazon.com/about-aws/whats-new/2020/07/announcing-new-amazon-ec2-instances-powered-aws-graviton2-processors/) and provide high compute coupled with fast NVMe storage, which makes them a good fit to power Elastic workloads. In addition, Graviton2 VMs also offer more than a 20% improvement in price-performance over comparable Intel chipsets. - -In addition to AWS Graviton2 instances, Amazon EC2 (AWS) C5d, M5d, I3, I3en, and D2/D3 instances are now available for Elastic Cloud deployments in all supported [AWS Cloud Regions](cloud://reference/cloud-hosted/ec-regions-templates-instances.md#ec-aws_regions). - -For specific AWS hardware and availability details, check the [Regional availability of instances per AWS region](ech-default-aws-configurations.md#aws-list-region) and the [AWS default provider instance configurations](ech-default-aws-configurations.md). - -## VM configurations [echvm_configurations] - -For the AWS infrastructure upgrade, we use the default instance type configurations provided by AWS which are unique to them. - -To make it easy to identify each instance type in AWS, a new common nomenclature is introduced. - -For example, Instance ID / SKU: `aws.es.datahot.i3` - -| | | -| --- | --- | -| `aws.*` | Denotes the cloud provider, AWS in this case with Azure in future cases. | -| `\*.es.datahot.*` | Denotes that this configuration is an Elasticsearch (`es`) cluster component that serves as a data node for hot content. Other options may be `datawarm`, `datacold`, `datafrozen` for data nodes, and `kibana`, `master`, and so on for other components. | -| `*.i3` | Denotes that this configuration is running on the AWS i3 instance family. | - -The new configuration naming convention aligns with the [data tiers](/manage-data/lifecycle/data-tiers.md) intended for each configuration type, replacing prior naming conventions of “highio”, “highcpu”, and so on. The following table details the new configurations for data nodes and compares them with prior naming conventions where applicable. - -| New config name | Notes | -| --- | --- | -| aws.es.datahot.i3 | This configuration maintains the same type of VM configuration as used in the previous config (“aws.data.highio.i3”) but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.datahot.i3en | This is a new configuration that is similar to the “aws.data.datahot.i3” config, but with more disk space to allow for longer retention in ingest use cases, or larger catalog in search use cases. | -| aws.es.datahot.m5d | This configuration maintains the same type of VM configuration as used in the previous config (“aws.data.highcpu.m5d”) but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.datahot.m6gd | This is a new configuration that is similar to the “aws.es.datahot.m5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.es.datahot.c5d | This is a new configuration that provides double the CPU capacity compared to “aws.es.datahot.m5d” config. It is intended for high throughput ingest use cases or intensive search use cases. | -| aws.es.datahot.c6gd | This is a new configuration that is similar to the “aws.es.datahot.c5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.es.datahot.r6gd | This is a new configuration powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.es.datawarm.d2, aws.es.datacold.d2 | These configurations maintain the same type of VM configuration as used in the previous config (“aws.data.highstorage.d2”) but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.datawarm.d3, aws.es.datacold.d3 | These configurations maintain the same type of VM configuration as used in the previous config (“aws.data.highstorage.d3”) but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.datawarm.i3en, aws.es.datacold.i3en | These configurations maintain the same type of VM configuration as used in the previous config (“aws.data.highstorage.i3en”) but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.datafrozen.i3en | This configuration maintains the same type of VM configuration as defined for (“aws.es.datacold.i3en”) config. | - -For a detailed price list, check the [Elastic Cloud price list](https://cloud.elastic.co/deployment-pricing-table?provider=aws). For a detailed specification of the new configurations, check [{{ecloud}} default provider instance configurations](ech-default-aws-configurations.md). - -The benefits of the new configurations are multifold: - -* By providing a net new configuration of C5d instances, there is a general boost of performance related to new chipsets and faster hardware. On average the boost we witnessed in select benchmarks can reach up to 15%, however, different workloads may exhibit different improvements. -* Introducing C6gd, M6gd & R6gd instances, powered by AWS Graviton 2, provides high compute coupled with fast NVMe storage and offer more than a 20% improvement in price-performance over comparable Intel chipsets. -* The existing family types have been extended in terms of disk capacity which translates to a more cost effective infrastructure which in some cases can save up to 80% when calculating cost by disk capacity. -* There are now more instance types to choose from in the hot tier. Rather than the traditional “highio” and “highcpu”, there are now six options to cover the hot data tier which allows to optimize cost/performance further. - -In addition to data nodes for storage and search, Elasticsearch nodes also have machine learning nodes, master nodes, and coordinating nodes. These auxiliary node types along with application nodes such as APM servers, Kibana, and Enterprise search have also been upgraded to the new C5d, C6gd, M5d, and M6gd instance types. Both auxiliary node and application node configurations are based on Elasticsearch data node configuration types shown in the previous table. - -| New config name | Notes | -| --- | --- | -| aws.es.master.c5d | Master nodes have been “upgraded” to use 4x the CPU with more memory and disk space as they had when based on “aws.master.r5d” config. This will help boost the overall performance and stability of clusters, as master nodes have a critical role in maintaining cluster state and controlling workloads. | -| aws.es.master.c6gd | This is a new configuration that is similar to the “aws.es.master.c5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.es.ml.m5d | ML nodes will maintain the same type of VM configuration as used in the previous config (“aws.ml.m5d”), but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.ml.m6gd | This is a new configuration that is similar to the “aws.es.ml.m5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.es.ml.c5d | This is a new configuration that is similar to the “aws.es.ml.m5d” config but with 2x more CPU per unit of RAM and more disk space. | -| aws.es.coordinating.m5d | Coordinating nodes will maintain the same type of VM configuration as used in the previous config (“aws.coordinating.m5d”), but will have a new name (and billing SKU) that is consistent with the new naming. | -| aws.es.coordinating.m6gd | This is a new configuration that is similar to the “aws.es.coordinating.m5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.kibana.c5d | Same “upgrade” for Kibana as that of master nodes. Will now use 4x the CPU with more memory and disk space. This ensures a more performant Kibana and helps with some client side aggregation, as well as responsive UI. | -| aws.kibana.c6gd | This is a new configuration that is similar to the “aws.kibana.c5d” config but with more disk space and similar RAM:CPU ratios. It is powered by AWS Graviton2 which offers a better price-performance over comparable Intel chipsets. | -| aws.apm.c5d | Same “upgrade” for APM as that of Kibana. Will now use 4x the CPU with more memory and disk space. | -| aws.integrationsserver.c5d | Same “upgrade” for Integrations Server as that of Kibana. Will now use 4x the CPU with more memory and disk space. | -| aws.enterprisesearch.c5d | Enterprisesearch nodes have been “upgraded” to use 2x the CPU with more memory and disk space as they had when based on “aws.enterprisesearch.m5d” config. | - - -## Selecting the right configuration for you [echselecting_the_right_configuration_for_you] - -While far from being a comprehensive guide for performance tuning, the following advice is provided for selecting the hot tier instance configuration: - -| Deployment template | Hot data tier instance configuration | Notes | -| --- | --- | --- | -| Storage Optimized | aws.es.datahot.i3 | Good for most ingestion use cases with 7-10 days of data available for fast access. Also good for light search use cases without heavy indexing or CPU needs. | -| Storage Optimized (Dense) | aws.es.datahot.i3en | Ideal for ingestion use cases with more than 10 days of data available for fast access. Also, good for light search use cases with very large data sets. | -| CPU Optimized | aws.es.datahot.c5d | Suitable for ingestion use cases with 1-4 days of data available for fast access and for search use cases with indexing and querying workloads. Provides the most CPU resources per unit of RAM. | -| CPU Optimized (ARM) | aws.es.datahot.c6gd | Suitable for ingestion use cases with 1-4 days of data available for fast access and for search use cases with indexing and querying workloads. Provides the most CPU resources per unit of RAM. | -| Vector Search Optimized (ARM) | aws.es.datahot.r6gd | Optimized for applications that leverage Vector Search and/or Generative AI. Also the optimal choice for utilizing ELSER for semantic search applications. Broadly suitable for all semantic search, text embedding, image search, and other Vector Search use cases. | -| General Purpose | aws.es.datahot.m5d | Suitable for ingestion use cases with 5-7 days of data available for fast access. Also good for search workloads with less-frequent indexing and medium to high querying loads. Provides a balance of storage, memory, and CPU. | -| General Purpose (ARM) | aws.es.datahot.m6gd | Suitable for ingestion use cases with 5-7 days of data available for fast access. Also good for search workloads with less-frequent indexing and medium to high querying loads. Provides a balance of storage, memory, and CPU. | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-azure-instance-configuration.md b/deploy-manage/deploy/elastic-cloud/ech-azure-instance-configuration.md deleted file mode 100644 index 6fe937fa58..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-azure-instance-configuration.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-azure-instance-configuration.html ---- - -# Elasticsearch Add-On for Heroku Azure instance configurations [ech-azure-instance-configuration] - -Azure [Ddv4](https://docs.microsoft.com/en-us/azure/virtual-machines/ddv4-ddsv4-series/), [Edsv4](https://docs.microsoft.com/en-us/azure/virtual-machines/edv4-edsv4-series/), [Fsv2](https://docs.microsoft.com/en-us/azure/virtual-machines/fsv2-series/), and [Lsv3](https://docs.microsoft.com/en-us/azure/virtual-machines/lsv3-series/) virtual machines (VM) are now available for Elastic Cloud deployments in all supported [Azure Cloud regions](cloud://reference/cloud-hosted/ec-regions-templates-instances.md#ec-azure_regions). These VMs provide additional combinations of compute, memory, and disk configurations to better fit your use-cases to optimize performance and cost. - -To learn about the Azure specific configurations, check: - -* [VM configurations](#ech-azure-vm-configurations) -* [Selecting the right configuration for you](#ech-azure-configuration-choose) -* [Azure default provider instance configurations](ech-default-azure-configurations.md) -* [Regional availability of instances per Azure region](ech-default-azure-configurations.md#ech-azure-list-region) - -## VM configurations [ech-azure-vm-configurations] - -For Azure, we use the default instance type configurations provided by Azure which are unique to them. To make it easy to identify each instance type in Azure, a new common nomenclature is introduced. - -For example, Instance ID / SKU: `azure.es.datahot.ddv4` - -| | | -| --- | --- | -| `azure.*` | Denotes the cloud provider, Azure in this case. | -| `\*.es.datahot.*` | Denotes that this configuration is an Elasticsearch (`es`) cluster component that serves as a data node for hot content. Other options may be `datawarm`, `datacold`, `datafrozen` for data nodes, and `kibana`, `master`, and so on for other components. | -| `*.ddv4` | Denotes that this configuration is running on the Azure Ddv4 VM series. | - -The new configuration naming convention aligns with the [data tiers](/manage-data/lifecycle/data-tiers.md) intended for each configuration type, replacing prior naming conventions of “highio”, “highcpu”, and so on. The following table details the new configurations for data nodes and compares them with prior naming conventions where applicable. - -| New config name | Notes | -| --- | --- | -| azure.es.datahot.edsv4 | This is a new configuration that replaces “azure.data.highio.l32sv2” or “azure.data.highio.e32sv3” config, but provides more disk space and similar RAM:CPU ratios. | -| azure.es.datahot.ddv4 | This is a new configuration that replaces “azure.data.highcpu.d64sv3” config, but provides more disk space to allow for longer retention in ingest use cases, or larger catalog in search use cases. | -| azure.es.datahot.fsv2 | This is a new configuration that provides double the CPU compared to “azure.es.datahot.ddv4” config. It is intended for high throughput ingest use cases or intensive search use cases. | -| azure.es.datahot.lsv3 | This is a new configuration powered by Intel Ice lake processor which provides similar RAM:CPU ratios as that of edsv4 but provides lower disk space. | -| azure.es.datawarm.edsv4, azure.es.datacold.edsv4 | This is a new configuration that replaces “azure.data.highstorage.e16sv3” config but provides more disk space. | -| azure.es.datafrozen.edsv4 | This is a new configuration that replaces “azure.es.datafrozen.lsv2” or “azure.es.datafrozen.esv3” config but provides more disk space. | - -For a detailed price list, check the [Elastic Cloud price list](https://cloud.elastic.co/deployment-pricing-table?provider=azure). For a detailed specification of the new configurations, check [{{ecloud}} default Azure instance configurations](ech-default-azure-configurations.md). - -The benefits of the new configurations are multifold: - -* By providing a net new configuration of fsv2 VM series, there is a general boost of performance related to new chipsets and faster hardware. -* The new instances provide more disk capacity as compared to existing VM series which translates to a more cost effective infrastructure which can save up to 80% when calculating cost by disk capacity. -* There are now more instances to choose from in the hot tier. Rather than the traditional “highio” and “highcpu”, there are now three options to cover the hot data tier which allows to optimize cost/performance further. - -In addition to data nodes for storage and search, Elasticsearch nodes also have machine learning nodes, master nodes, and coordinating nodes. These auxiliary node types along with application nodes such as APM servers, Kibana, and Enterprise search have also been upgraded to the new Fsv2 VM series. Both auxiliary node and application node configurations are based on Elasticsearch data node configuration types shown in the previous table. - -| New config name | Notes | -| --- | --- | -| azure.es.master.fsv2 | Master nodes now use 4x the CPU as they had when based on “azure.master.e32sv3” config. This will help boost the overall performance and stability of clusters, as master nodes have a critical role in maintaining cluster state and controlling workloads. | -| azure.es.ml.fsv2 | ML nodes now use 2x the CPU as they had when based on “azure.ml.d64sv3” config. | -| azure.es.coordinating.fsv2 | Coordinating nodes now use 2x the CPU as they had when based on “azure.coordinating.d64sv3” config. | -| azure.kibana.fsv2 | Kibana nodes now use 4x the CPU as they had when based on “azure.kibana.e32sv3” config. This ensures a more performant Kibana and helps with some client side aggregation, as well as responsive UI. | -| azure.apm.fsv2 | APM nodes now use 4x the CPU as they had when based on “azure.apm.e32sv3” config. | -| azure.integrationsserver.fsv2 | Integrations Server nodes now use 4x the CPU as they had when based on “azure.integrationsserver.e32sv3” config. | -| azure.enterprisesearch.fsv2 | Enterprisesearch Server nodes now use 2x the CPU as they had when based on “azure.enterprisesearch.d64sv3” config. | - - -## Selecting the right configuration for you [ech-azure-configuration-choose] - -While far from being a comprehensive guide for performance tuning, the following advice is provided for selecting the hot tier instance configuration: - -| Deployment template | Hot data tier instance configuration | Notes | -| --- | --- | --- | -| Storage Optimized | azure.es.datahot.edsv4 | Good for most ingestion use cases with 7-10 days of data available for fast access. Also good for light search use cases without heavy indexing or CPU needs. | -| CPU Optimized | azure.es.datahot.fsv2 | Suitable for ingestion use cases with 1-4 days of data available for fast access and for search use cases with indexing and querying workloads. Provides the most CPU resources per unit of RAM. | -| Vector Search Optimized | azure.es.datahot.lsv3 | Optimized for applications that leverage Vector Search and/or Generative AI. Also the optimal choice for utilizing ELSER for semantic search applications. Broadly suitable for all semantic search, text embedding, image search, and other Vector Search use cases. | -| General Purpose | azure.es.datahot.ddv4 | Suitable for ingestion use cases with 5-7 days of data available for fast access. Also good for search workloads with less-frequent indexing and medium to high querying loads. Provides a balance of storage, memory, and CPU. | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-default-aws-configurations.md b/deploy-manage/deploy/elastic-cloud/ech-default-aws-configurations.md deleted file mode 100644 index 7d010e4525..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-default-aws-configurations.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-default-aws-configurations.html ---- - -# Elasticsearch Add-On for Heroku AWS default provider instance configurations [ech-default-aws-configurations] - -Following are the preferred instance types / machine configurations, storage types, disk to memory ratios, and virtual CPU to RAM ratios for all instance configurations available on {{ech}} and provided by AWS. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | Storage Type1 | Disk:Memory Ratio2 | vCPU/RAM Ratio | -| --- | --- | --- | --- | --- | -| aws.es.datahot.i3 | i3 | NVMe | 30:1 | 0.138 | -| aws.es.datahot.i3en | i3en | NVMe | 80:1 | 0.133 | -| aws.es.datahot.m5d | m5d | NVMe | 10:1 | 0.267 | -| aws.es.datahot.m6gd | m6gd | NVMe | 15:1 | 0.267 | -| aws.es.datahot.c5d | c5d | NVMe | 12:1 | 0.529 | -| aws.es.datahot.c6gd | c6gd | NVMe | 30:1 | 0.533 | -| aws.es.datahot.r6gd | r6gd | NVMe | 6:1 | 0.133 | -| aws.es.datawarm.d2 | d2 | HDD | 160:1 | 0.138 | -| aws.es.datawarm.d3 | d3 | HDD | 190:1 | 0.133 | -| aws.es.datawarm.i3en | i3en | NVMe | 80:1 | 0.133 | -| aws.es.datacold.d2 | d2 | HDD | 160:1 | 0.138 | -| aws.es.datacold.d3 | d3 | HDD | 190:1 | 0.133 | -| aws.es.datacold.i3en | i3en | NVMe | 80:1 | 0.133 | -| aws.es.datafrozen.i3en | i3en | NVMe | 75:1 | 0.133 | - - -## Additional instances [ech-aws-additional-instances] - -Following are the preferred instance type / configuration and virtual CPU to RAM ratios for additional instance configurations available on {{ech}} and provided by AWS. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | vCPU/RAM Ratio | -| --- | --- | --- | -| aws.es.master.c5d | c5d | 0.529 | -| aws.es.master.c6gd | c6gd | 0.533 | -| aws.es.ml.c5d | c5d | 0.529 | -| aws.es.ml.m5d | m5d | 0.267 | -| aws.es.ml.m6gd | m6gd | 0.267 | -| aws.es.coordinating.m5d | m5d | 0.267 | -| aws.es.coordinating.m6gd | m6gd | 0.267 | -| aws.kibana.c5d | c5d | 0.529 | -| aws.kibana.c6gd | c6gd | 0.533 | -| aws.apm.c5d | c5d | 0.529 | -| aws.integrationsserver.c5d | c5d | 0.529 | -| aws.enterprisesearch.c5d | c5d | 0.529 | - -1 Preferred instance and storage types are subject to provider availability. To learn more about our provider instances, check the [AWS](https://aws.amazon.com/ec2/instance-types) reference page. - -2 Ratios are estimations. - -## Regional availability of instances per AWS region [aws-list-region] - -The following table contains the complete list of instances available in Elastic Cloud deployments per AWS region: - -| Regions | Instances | | | | | | | | | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| | C5d | C6gd | C5n | M5dn | D2 | D3 | I3 | I3en | M5d | M6gd | R6gd | -| Africa (Cape Town) | ✓ | | | | ✓ | | ✓ | ✓ | ✓ | | | -| Asia Pacific (Hong Kong) | ✓ | | | | ✓ | | ✓ | ✓ | ✓ | | | -| Asia Pacific (Mumbai) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Asia Pacific (Singapore) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Asia Pacific (Seoul) | ✓ | | | | ✓ | | ✓ | ✓ | ✓ | | | -| Asia Pacific (Sydney) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Asia Pacific (Tokyo) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Canada (Central) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | | ✓ | -| Europe (Frankfurt) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Europe (Zurich) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | | -| Europe (Ireland) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| Europe (London) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | | -| Europe (Milan) | ✓ | | | | ✓ | | ✓ | ✓ | ✓ | | | -| Europe (Paris) | ✓ | ✓ | | | ✓ | | ✓ | ✓ | ✓ | | ✓ | -| Europe (Stockholm) | ✓ | ✓ | | | ✓ | | ✓ | ✓ | ✓ | ✓ | | -| Middle East (Bahrain) | ✓ | | | | ✓ | | ✓ | ✓ | ✓ | | | -| South America (São Paulo) | ✓ | | | | | | ✓ | ✓ | ✓ | | | -| US East (N. Virginia) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| US East (Ohio) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| US West (N. California) | ✓ | ✓ | | | ✓ | | ✓ | ✓ | ✓ | ✓ | ✓ | -| US West (Oregon) | ✓ | ✓ | | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | -| US East GovCloud (N. Virginia) | | | ✓ | ✓ | | | | ✓ | | | | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-default-azure-configurations.md b/deploy-manage/deploy/elastic-cloud/ech-default-azure-configurations.md deleted file mode 100644 index fc9c5755f0..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-default-azure-configurations.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-default-azure-configurations.html ---- - -# Elasticsearch Add-On for Heroku Azure default provider instance configurations [ech-default-azure-configurations] - -Following are the preferred instance types / machine configurations, storage types, disk to memory ratios, and virtual CPU to RAM ratios for all instance configurations available on {{ech}} and provided by Azure. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | Storage Type1 | Disk:Memory Ratio2 | vCPU/RAM Ratio | -| --- | --- | --- | --- | --- | -| $$$azure.es.datahot.edsv4$$$ `azure.es.datahot.edsv4` | e8dsv4 | Standard Managed Disks (SSD) | 35:1 | 0.133 | -| $$$azure.es.datahot.ddv4$$$ `azure.es.datahot.ddv4` | d16dv4 | Standard Managed Disks (SSD) | 35:1 | 0.267 | -| $$$azure.es.datahot.fsv2$$$ `azure.es.datahot.fsv2` | f32sv2 | Standard Managed Disks (SSD) | 35:1 | 0.533 | -| $$$azure.es.datahot.lsv3$$$ `azure.es.datahot.lsv3` | l8sv3 | NVMe | 28:1 | 0.133 | -| $$$azure.es.datawarm.edsv4$$$ `azure.es.datawarm.edsv4` | e8dsv4 | Standard Managed Disks (HDD) | 200:1 | 0.133 | -| $$$azure.es.datacold.edsv4$$$ `azure.es.datacold.edsv4` | e8dsv4 | Standard Managed Disks (HDD) | 200:1 | 0.133 | -| $$$azure.es.datafrozen.edsv4$$$ `azure.es.datafrozen.edsv4` | e8dsv4 | Standard Managed Disks (SSD) | 90:1 | 0.133 | - - -## Additional instances [ech-additional-instances] - -Following are the preferred instance type / configuration and virtual CPU to RAM ratios for additional instance configurations available on {{ech}} and provided by Azure. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | vCPU/RAM Ratio | -| --- | --- | --- | -| $$$azure.es.master.fsv2$$$`azure.es.master.fsv2` | f32sv2 | 0.533 | -| $$$azure.es.ml.fsv2$$$`azure.es.ml.fsv2` | f32sv2 | 0.533 | -| $$$azure.es.coordinating.fsv2$$$`azure.es.coordinating.fsv2` | f32sv2 | 0.533 | -| $$$azure.kibana.fsv2$$$`azure.kibana.fsv2` | f32sv2 | 0.533 | -| $$$azure.apm.fsv2$$$`azure.apm.fsv2` | f32sv2 | 0.533 | -| $$$azure.integrationsserver.fsv2$$$`azure.integrationsserver.fsv2` | f32sv2 | 0.533 | -| $$$azure.enterprisesearch.fsv2$$$`azure.enterprisesearch.fsv2` | f32sv2 | 0.533 | - -1 Preferred instance and storage types are subject to provider availability. To learn more about our provider instances, check [AWS](https://aws.amazon.com/ec2/instance-types), [Azure](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/), and [GCP](https://cloud.google.com/compute/docs/machine-types) reference pages. - -2 Ratios are estimations. - -## Regional availability of instances per Azure region [ech-azure-list-region] - -The following table contains the complete list of instances available in Elastic Cloud deployments per Azure region: - -| Regions | Instances | | | | -| --- | --- | --- | --- | --- | -| | Edsv4 | Ddv4 | Fsv2 | Lsv3 | -| Australia East (New South Wales) | ✓ | ✓ | ✓ | ✓ | -| Brazil South (São Paulo) | ✓ | ✓ | ✓ | ✓ | -| Canada Central (Toronto) | ✓ | ✓ | ✓ | ✓ | -| Central India (Pune) | ✓ | ✓ | ✓ | ✓ | -| Central US (Iowa) | ✓ | ✓ | ✓ | | -| East US (Virginia) | ✓ | ✓ | ✓ | ✓ | -| East US 2 (Virginia) | ✓ | ✓ | ✓ | ✓ | -| France Central (Paris) | ✓ | ✓ | ✓ | ✓ | -| Japan East (Tokyo) | ✓ | ✓ | ✓ | ✓ | -| North Europe (Ireland) | ✓ | ✓ | ✓ | ✓ | -| South Africa North (Johannesburg) | ✓ | ✓ | ✓ | | -| South Central US (Texas) | ✓ | ✓ | ✓ | ✓ | -| South East Asia (Singapore) | ✓ | ✓ | ✓ | ✓ | -| UK South (London) | ✓ | ✓ | ✓ | ✓ | -| West Europe (Netherlands) | ✓ | ✓ | ✓ | ✓ | -| West US 2 (Washington) | ✓ | ✓ | ✓ | ✓ | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-default-gcp-configurations.md b/deploy-manage/deploy/elastic-cloud/ech-default-gcp-configurations.md deleted file mode 100644 index 44eb14bd4e..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-default-gcp-configurations.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-default-gcp-configurations.html ---- - -# Elasticsearch Add-On for Heroku GCP default provider instance configurations [ech-default-gcp-configurations] - -Following are the preferred instance types / machine configurations, storage types, disk to memory ratios, and virtual CPU to RAM ratios for all instance configurations available on {{ech}} and provided by GCP. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | Storage Type1 | Disk:Memory Ratio2 | vCPU/RAM Ratio | -| --- | --- | --- | --- | --- | -| gcp.es.datahot.n2.68x10x45 | N2 | NVMe | 45:1 | 0.156 | -| gcp.es.datahot.n2.68x10x95 | N2 | NVMe | 95:1 | 0.156 | -| gcp.es.datahot.n2.68x16x45 | N2 | NVMe | 45:1 | 0.250 | -| gcp.es.datahot.n2.68x32x45 | N2 | NVMe | 45:1 | 0.500 | -| gcp.es.datahot.n2d.64x8x11 | N2d | NVMe | 11:1 | 0.133 | -| gcp.es.datawarm.n2.68x10x190 | N2 | Zonal standard persistent disk | 190:1 | 0.156 | -| gcp.es.datacold.n2.68x10x190 | N2 | Zonal standard persistent disk | 190:1 | 0.156 | -| gcp.es.datafrozen.n2.68x10x95 | N2 | NVMe | 95:1 | 0.156 | - - -## Additional instances [ech-gcp-additional-instances] - -Following are the preferred instance configuration and virtual CPU to RAM ratios for additional instance configurations available on {{ech}} and provided by GCP. - -| Instance configuration | Preferred Instance Type or Machine Configuration1 | vCPU/RAM Ratio | -| --- | --- | --- | -| gcp.es.master.n2.68x32x45 | N2 | 0.500 | -| gcp.es.ml.n2.68x16x45 | N2 | 0.250 | -| gcp.es.ml.n2.68x32x45 | N2 | 0.500 | -| gcp.es.coordinating.n2.68x16x45 | N2 | 0.250 | -| gcp.kibana.n2.68x32x45 | N2 | 0.500 | -| gcp.apm.n2.68x32x45 | N2 | 0.500 | -| gcp.integrationsserver.n2.68x32x45 | N2 | 0.500 | -| gcp.enterprisesearch.n2.68x32x45 | N2 | 0.500 | - -1 Preferred instance and storage types are subject to provider availability. To learn more about our provider instances, check the [GCP](https://cloud.google.com/compute/docs/machine-types) reference page. - -2 Ratios are estimations. - -## Regional availability of instances per GCP region [ech-gcp-list-region] - -The following table contains the complete list of instances available in Elastic Cloud deployments per GCP region: - -| Regions | Instances | | -| --- | --- | --- | -| | N2 | N2d | -| Asia Pacific East 1 (Taiwan) | ✓ | ✓ | -| Asia Pacific Northeast 1 (Tokyo) | ✓ | ✓ | -| Asia Pacific Northeast 3 (Seoul) | ✓ | ✓ | -| Asia Pacific South 1 (Mumbai) | ✓ | ✓ | -| Asia Pacific Southeast 1 (Singapore) | ✓ | ✓ | -| Asia Pacific Southeast 2 (Jakarta) | ✓ | | -| Australia Southeast 1 (Sydney) | ✓ | ✓ | -| Europe North 1 (Finland) | ✓ | ✓ | -| Europe West 1 (Belgium) | ✓ | ✓ | -| Europe West 2 (London) | ✓ | ✓ | -| Europe West 3 (Frankfurt) | ✓ | ✓ | -| Europe West 4 (Netherlands) | ✓ | ✓ | -| Europe West 9 (Paris) | ✓ | ✓ | -| ME West 1 (Tel Aviv) | ✓ | ✓ | -| North America Northeast 1 (Montreal) | ✓ | ✓ | -| South America East 1 (Sao Paulo) | ✓ | ✓ | -| US Central 1 (Iowa) | ✓ | ✓ | -| US East 1 (South Carolina) | ✓ | ✓ | -| US East 4 (N. Virginia) | ✓ | ✓ | -| US West 1 (Oregon) | ✓ | ✓ | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-gcp-instance-configuration.md b/deploy-manage/deploy/elastic-cloud/ech-gcp-instance-configuration.md deleted file mode 100644 index a3598c9f53..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-gcp-instance-configuration.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-gcp-instance-configuration.html ---- - -# Elasticsearch Add-On for Heroku GCP instance configurations [ech-gcp-instance-configuration] - -Google Compute Engine (GCE) N2 general purpose VM types are now available for Elastic Cloud deployments in all supported [Google Cloud regions](cloud://reference/cloud-hosted/ec-regions-templates-instances.md#ec-gcp_regions). [N2](https://cloud.google.com/compute/docs/machine-types) VMs have a better mix of vCPU, RAM, and internal disk, and are up to 50% more cost effective when compared to N1 VM types. In addition to N2, we also provide N2D VMs across the Google Cloud regions. - -To learn about the GCE specific configurations, check: - -* [VM configurations](#ech-gcp-vm-configurations) -* [Selecting the right configuration for you](#ech-gcp-configuration-choose) -* [GCP default provider instance configurations](ech-default-gcp-configurations.md) -* [Regional availability of instances per GCP region](ech-default-gcp-configurations.md#ech-gcp-list-region) - -## VM configurations [ech-gcp-vm-configurations] - -For the Google Cloud infrastructure upgrade, rather than using default baseline configurations, [custom machine types](https://cloud.google.com/custom-machine-types) unique to Google Cloud are used so individual parameters of each VM can be fine tuned to fit the right blend of RAM:CPU:Disk. To accommodate the custom configuration, a new common nomenclature is introduced to help you easily identify each VM type. This will apply eventually to AWS and Azure instances as well, as we roll out newer versions of VMs for these providers. - -For example, Instance ID / SKU: `gcp.es.datahot.n2.68x10x45` - -| | | -| --- | --- | -| `gcp.*` | Denotes the cloud provider, GCP in this case or AWS/Azure in future cases. | -| `\*.es.datahot.*` | Denotes that this configuration is an Elasticsearch (`es`) cluster component that serves as a data node for hot content. Other options may be `datawarm`, `datacold`, `datafrozen` for data nodes, and `kibana`, `master`, and so on for other components. | -| `\*.n2.*` | Denotes that this configuration is running on the GCP N2 family. | -| `*.68x10x45` | Denotes the resource configuration, delimited by “x”.
* The first argument (`68`) denotes the total gross RAM capacity of the instance. Normally we use 4GB of that for utilities and therefore this configuration has a “usable RAM” of 64GB.
* The second argument (`10`) denotes the number of vCPUs allocated to the entire machine.
* The third argument denotes the ratio of RAM to storage capacity as in 1:X. In this case, for each 1GB of RAM, you will have 45 GB of disk to store Elasticsearch data. | - -The new configuration naming convention aligns with the [data tiers](/manage-data/lifecycle/data-tiers.md) intended for each configuration type, replacing prior naming conventions of “highio”, “highcpu”, and so on. The following table details the new configurations for data nodes and compares them with prior naming conventions where applicable. - -| New config name | Notes | -| --- | --- | -| gcp.es.datahot.n2.68x10x45 | This configuration replaces “highio”, which is based on N1 with 1:30 RAM:disk and similar RAM:CPU ratios. | -| gcp.es.datahot.n2.68x10x95 | This is a new configuration that is similar to the first, but with more disk space to allow for longer retention in ingest use cases, or larger catalog in search use cases. | -| gcp.es.datahot.n2.68x16x45 | This configuration replaces “highcpu”, which is based on N1 with 1:8 RAM:disk and similar RAM:CPU ratios. | -| gcp.es.datahot.n2.68x32x45 | This is a new configuration that provides double the CPU capacity compared to “highcpu” or [68-16-1:45] configuration. It is intended for high throughput ingest use cases or intensive search use cases. | -| gcp.es.datahot.n2d.64x8x11 | This is a new configuration powered by AMD processors which offers a better price-performance compared to Intel processors. | -| gcp.es.datawarm.n2.68x10x190, gcp.es.datacold.n2.68x10x190 | These configurations replace “highstorage”, which is based on N1 with 1:160 RAM:disk and similar RAM:CPU ratios. | -| gcp.es.datafrozen.n2.68x10x95 | This configuration replaces the (short lived) gcp.es.datafrozen.n2d.64x8x95 configuration we used for the frozen cache tier. n2d was based on the AMC epyc processor but we found that the Intel-based configuration provides a slightly better cost/performance ratio. We also tweaked the RAM/CPU ratios to align to other configurations and benchmarks. | - -For a detailed price list, check the [Elastic Cloud deployment pricing table](https://cloud.elastic.co/deployment-pricing-table?provider=gcp). For a detailed specification of the new configurations, check [{{ecloud}} default GCP instance configurations](ech-default-gcp-configurations.md). - -The benefits of the new configurations are multifold: - -1. By using newer generations of N2 machines, there is a general boost of performance related to new chipsets and faster hardware. On average the boost we witnessed in select benchmarks can reach up to 15%, however, different workloads may exhibit different improvements. -2. The existing family types have been extended in terms of disk capacity which translates to a more cost effective infrastructure which in some cases can save up to 80% when calculating cost by disk capacity. -3. There are now more instance types to choose from in the hot tier. Rather than the traditional “highio” and “highcpu”, there are now four options to cover the hot data tier which allows to optimize cost/performance further. - -In addition to data nodes for storage and search, Elasticsearch nodes also have machine learning nodes, master nodes, and coordinating nodes. These auxiliary node types along with application nodes such as APM servers and Kibana instances have also been upgraded to the new N2 instance types. Both auxiliary node and application node configurations are based on Elasticsearch data node configuration types shown in the previous table. - -| New config name | Notes | -| --- | --- | -| gcp.es.master.n2.68x32x45 | Master nodes will now be based on the highest CPU rich configuration (68:32). In the past, master nodes were based on a configuration that had ¼ of the CPU for each unit of RAM (was called “highmem”). This will help boost the overall performance and stability of clusters, as master nodes have a critical role in maintaining cluster state and controlling workloads. | -| gcp.es.ml.n2.68x16x45 | ML nodes will maintain the same type of VM configuration as in the past, but will have a new name (and billing SKU) that is consistent with the rest of the naming. | -| gcp.es.ml.n2.68x32x45 | This is a new configuration that is similar to the “gcp.es.ml.n2.68x16x45” config but with 2x more CPU per unit of RAM and similar storage ratio. | -| gcp.es.coordinating.n2.68x16x45 | Same as ML nodes - no configuration change, just a new name. | -| gcp.kibana.n2.68x32x45 | Kibana nodes have been upgraded two steps up as well, to use 4x the CPU as they had when based on “highmem”. This ensures a more performant Kibana and helps with some client side aggregation, as well as responsive UI. | -| gcp.apm.n2.68x32x45 | Same upgrade for APM. Will now use 4x the CPU. | -| gcp.integrationsserver.n2.68x32x45 | Same upgrade for Integrations Server. Will now use 4x the CPU. | - -## Selecting the right configuration for you [ech-gcp-configuration-choose] - -While far from being a comprehensive guide for performance tuning, the following advice is provided for selecting the hot tier instance configuration: - -| Deployment template | Hot data tier instance configuration | Notes | -| --- | --- | --- | -| Storage Optimized | gcp.es.datahot.n2.68x10x45 | Consider this default configuration for ingest use cases that require ~7-10 days of retention, or for light search use cases that don’t have significant index changes or CPU utilization. | -| Storage Optimized (Dense) | gcp.es.datahot.n2.68x10x95 | Consider this dense storage option for ingest use cases that have a longer retention period of the hot tier, or for light search use cases that have a significant catalog size. | -| CPU Optimized | gcp.es.datahot.n2.68x32x45 | Consider this configuration for ingest use cases that require ~1-4 days of retention, or for heavyweight search use cases that require significant and consistent indexing or high query load. | -| Vector Search Optimized | gcp.es.datahot.n2d.64x8x11 | Optimized for applications that leverage Vector Search and/or Generative AI. Also the optimal choice for utilizing ELSER for semantic search applications. Broadly suitable for all semantic search, text embedding, image search, and other Vector Search use cases. | -| General Purpose | gcp.es.datahot.n2.68x16x45 | Consider this configuration for ingest use cases that require ~5-7 days of retention, or for moderate load search use cases that require occasional indexing or medium to high query load. | - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-get-help.md b/deploy-manage/deploy/elastic-cloud/ech-get-help.md deleted file mode 100644 index 3c359d9069..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-get-help.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-get-help.html ---- - -# Getting help [ech-get-help] - -With your Elasticsearch Add-On for Heroku subscription, you get access to support from the creators of Elasticsearch, Kibana, Beats, Logstash, and much more. We’re here to help! - - -## How do I open a support case? [echhow_do_i_open_a_support_case] - -All roads lead to the Elastic Support Portal, where you can access to all your cases, subscriptions, and licenses. - -As an Elasticsearch Add-On for Heroku customer, you will receive an email with instructions how to log in to the Support Portal, where you can track both current and archived cases. If you are a new customer who just signed up for Elasticsearch Add-On for Heroku, it can take a few hours for your Support Portal access to be set up. If you have questions, reach out to us at `support@elastic.co`. - -::::{note} -With the release of the new Support Portal, even if you have an existing account, you might be prompted to update your password. -:::: - - -There are three ways you can get to the portal: - -* Go directly to the Support Portal: [http://support.elastic.co](http://support.elastic.co) -* From the Elasticsearch Add-On for Heroku Console: Go to the [Support page](https://cloud.elastic.co/support?page=docs&placement=docs-body) or select the support icon, that looks like a life preserver, on any page in the console. -* Contact us by email: `support@elastic.co` - - If you contact us by email, please use the email address that you registered with, so that we can help you more quickly. If you are using a distribution list as your registered email, you can also register a second email address with us. Just open a case to let us know the name and email address you would like to be added. - - -When opening a case, there are a few things you can do to get help faster: - -* Include the deployment ID that you want help with, especially if you have several deployments. The deployment ID can be found on the overview page for your cluster in the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -* Describe the problem. Include any relevant details, including error messages you encountered, dates and times when the problem occurred, or anything else you think might be helpful. -* Upload any pertinent files. - - -## What level of support can I expect? [echwhat_level_of_support_can_i_expect] - -Support is governed by the [Elasticsearch Add-On for Heroku Standard Terms of Service](https://www.elastic.co/legal/terms-of-service/cloud). The level of support you can expect to receive applies to your Elasticsearch Add-On for Heroku environment only and depends on your subscription level: - -Elasticsearch Add-On for Heroku Standard subscriptions -: Support is provided by email or through the Elastic Support Portal. The main focus of support is to ensure your Elasticsearch Add-On for Heroku deployment shows a green status and is available. There is no guaranteed initial or ongoing response time, but we do strive to engage on every issue within three business days. We do not offer weekend coverage, so we respond Monday through Friday only. To learn more, check [Working with Elastic Support Elasticsearch Add-On for Heroku Standard](https://www.elastic.co/support/welcome/cloud). - -Elasticsearch Add-On for Heroku Gold and Platinum subscriptions -: Support is handled by email or through the Elastic Support Portal. Provides guaranteed response times for support issues, better support coverage hours, and support contacts at Elastic. Also includes support for how-to and development questions. The exact support coverage depends on whether you are a Gold or Platinum customer. To learn more, check [Elasticsearch Add-On for Heroku Premium Support Services Policy](https://www.elastic.co/legal/support_policy/cloud_premium). - -::::{note} -If you are in free trial, you are also eligible to get the {{ecloud}} Standard level support for as long as the trial is active. -:::: - - -If you are on an Elasticsearch Add-On for Heroku Standard subscription and you are interested in moving to Gold or Platinum support, please [contact us](https://www.elastic.co/cloud/contact). We also recommend that you read our best practices guide for getting the most out of your support experience: [https://www.elastic.co/support/welcome](https://www.elastic.co/support/welcome). - - -## Join the community forums [echjoin_the_community_forums] - -Elasticsearch, Logstash, and Kibana enjoy the benefit of having vibrant and helpful communities. You have our assurance of high-quality support and single source of truth as an Elasticsearch Add-On for Heroku customer, but the Elastic community can also be a useful resource for you whenever you need it. - -::::{tip} -As of May 1, 2017, support for Elasticsearch Add-On for Heroku **Standard** customers has moved from the Discuss forum to our link: [Elastic Support Portal](https://support.elastic.co). You should receive login instructions by email. We will also monitor the forum and help you get into the Support Portal, in case you’re unsure where to go. -:::: - - -If you have any technical questions that are not for our Support team, hop on our [Elastic community forums](https://discuss.elastic.co/) and get answers from the experts in the community, including people from Elastic. diff --git a/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing-version.md b/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing-version.md deleted file mode 100644 index 76755cc45f..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing-version.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-installing-version.html ---- - -# Install a specific version and plugins [ech-getting-started-installing-version] - -If you want your add-on to run a specific version of Elasticsearch, use the `--elasticsearch-version` parameter. We also provide many of the plugins that are available for Elasticsearch. You use the `--plugins` parameter to specify a comma-separated list of plugins that you want installed. - -To find which Elasticsearch versions and plugins are currently available, you can omit the version to default to the latest one and add plugins later on from the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). To use your own custom plugins, you can upload and select these plugins in the console as well. - -For example: Install the add-on version 6.8.23 and include the phonetic analysis plugin for MY_APP: - -```bash -heroku addons:create foundelasticsearch --elasticsearch-version 6.8.23 --plugins analysis-phonetic --app MY_APP -``` - -After the add-on gets added, you can perform future version upgrades and plugin changes through the [console](ech-getting-started-accessing.md). - diff --git a/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing.md b/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing.md deleted file mode 100644 index d2d1d7e331..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-getting-started-installing.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-installing.html ---- - -# Install the add-on [ech-getting-started-installing] - -These steps walk you through installing the Elasticsearch Add-On for Heroku from the Heroku CLI. You can either install the latest default version of the add-on or you can install a specific version and include plugins at the same time. - - -## Before you begin [echbefore_you_begin] - -The installation steps in this section assume that you have a basic working knowledge of the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) and are familiar with using the command line. To work with the Elasticsearch Add-On for Heroku from the command line, you need to have the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) already installed. - -If you prefer to install the add-on through your web browser, go to the [Elasticsearch add-on](https://elements.heroku.com/addons/foundelasticsearch) page in the Elements Marketplace, select **Install Elasticsearch**, pick the add-on plan you want, and select **Provision add-on**. - - -## Steps [echsteps] - -To install the latest add-on for MY_APP using the Heroku CLI: - -```bash -heroku addons:create foundelasticsearch --app MY_APP -``` - -After the Elasticsearch Add-On for Heroku gets added, you can find the canonical URL you use to access your newly provisioned cluster in the configuration for the app. Look for the `FOUNDELASTICSEARCH_URL` setting when you grep on the output of the `heroku config` command: - -```bash -heroku config --app MY_APP | grep FOUNDELASTICSEARCH_URL -FOUNDELASTICSEARCH_URL: https://74f176887fdef36bb51e6e37nnnnnnnn.us-east-1.aws.found.io -``` - - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-getting-started-next-steps.md b/deploy-manage/deploy/elastic-cloud/ech-getting-started-next-steps.md deleted file mode 100644 index 1b3c02768f..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-getting-started-next-steps.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-next-steps.html ---- - -# Next steps [ech-getting-started-next-steps] - -Now that you have provisioned your first deployment, you’re ready to index data into the deployment and explore the advanced capabilities of Elasticsearch Add-On for Heroku. - - -## Index data [ech-ingest-data] - -It’s why you’re here right? You’re looking to solve an issue or improve your experience with your data. - -There are several ways to ingest data into the deployment: - -* Use the sample data available from the Kibana home page in versions 6.4.0 and later, without loading your own data. There are multiple data sets available and you can add them with one click. -* Got existing Elasticsearch data? Consider your [migration options](../../../manage-data/migrate.md). - - -## Increase security [ech-increase-security] - -You might want to add more layers of security to your deployment, such as: - -* Add more users to the deployment with third-party authentication providers and services like [SAML](../../users-roles/cluster-or-deployment-auth/saml.md), [OpenID Connect](../../users-roles/cluster-or-deployment-auth/openid-connect.md), or [Kerberos](../../users-roles/cluster-or-deployment-auth/kerberos.md). -* Do not use clients that only support HTTP to connect to Elastic Cloud. If you need to do so, you should use a reverse proxy setup. -* Create [traffic filters](../../security/traffic-filtering.md) and apply them to your deployments. -* If needed, you can [reset](../../users-roles/cluster-or-deployment-auth/built-in-users.md) the `elastic` password. - - -## Scale or adjust your deployment [echscale_or_adjust_your_deployment] - -You might find that you need a larger deployment for the workload. Or maybe you want to upgrade the Elasticsearch version for the latest features. Perhaps you’d like to add some plugins, enable APM, or machine learning. All of this can be done after provisioning by [changing your deployment configuration](cloud-hosted.md). - diff --git a/deploy-manage/deploy/elastic-cloud/ech-licensing.md b/deploy-manage/deploy/elastic-cloud/ech-licensing.md deleted file mode 100644 index 0947a8014d..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-licensing.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-licensing.html ---- - -# Subscription levels [ech-licensing] - -For more information on what is available with different subscription levels, check [Elasticsearch Add-On for Heroku Subscriptions](https://www.elastic.co/elasticsearch/service/pricing). You are entitled to use all of the features in Elasticsearch Add-On for Heroku that match your subscription level. Please use them to your heart’s content. - -Your subscription determines [which features are available](https://www.elastic.co/subscriptions/cloud). For example, machine learning requires a Platinum or Private subscription and is not available if you upgrade to a Gold subscription. Similarly, SAML Single Sign-On requires an Enterprise subscription. - diff --git a/deploy-manage/deploy/elastic-cloud/ech-migrate-data-internal.md b/deploy-manage/deploy/elastic-cloud/ech-migrate-data-internal.md deleted file mode 100644 index 2fdcffb97c..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-migrate-data-internal.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrate-data-internal.html ---- - -# Migrate internal indices [ech-migrate-data-internal] - -When you migrate your Elasticsearch data into a new infrastructure you may also want to migrate your Elasticsearch internal indices, specifically the `.kibana` index and the `.security` index. - -There are two ways to migrate the internal Elasticsearch indices: - -1. Reindex the indices from a remote cluster. -2. Restore the indices from a snapshot. - -To reindex internal indices from a remote cluster, you can follow the same steps that you use to reindex regular indices when you [migrate your Elasticsearch data indices](../../../manage-data/migrate.md#ech-reindex-remote). - -To restore internal indices from a snapshot, the procedure is a bit different from migrating Elasticsearch data indices. Use these steps to restore internal indices from a snapshot: - -1. On your old Elasticsearch cluster, choose an option to get the name of your snapshot repository bucket: - - ```sh - GET /_snapshot - GET /_snapshot/_all - ``` - -2. Get the snapshot name: - - ```sh - GET /_snapshot/NEW-REPOSITORY-NAME/_all - ``` - - The output for each entry provides a `"snapshot":` value which is the snapshot name. - - ``` - { - "snapshots": [ - { - "snapshot": "scheduled-1527616008-instance-0000000004", - ``` - -3. To restore internal Elasticsearch indices, you need to register the snapshot repository in `read-only` mode. To do so, first add the authentication information for the repository to the Elasticsearch Add-On for Heroku keystore, following the steps for [AWS S3](../../tools/snapshot-and-restore/ec-aws-custom-repository.md), [Google Cloud Storage](../../tools/snapshot-and-restore/ec-gcs-snapshotting.md), or [Azure Blog storage](../../tools/snapshot-and-restore/ec-azure-snapshotting.md). -4. To register a read-only repository, open the Elasticsearch [API console](ech-api-console.md) or the Kibana [Dev Tools page](../../../explore-analyze/query-filter/tools.md) and run the [Read-only URL repository](../../tools/snapshot-and-restore/read-only-url-repository.md) API call. -5. Once the repository has been registered and verified, you are ready to restore the internal indices to your new cluster, either all at once or individually. - - * **Restore all internal indices** - - Run the following API call to restore all internal indices from a snapshot to the cluster: - - ```sh - POST /_snapshot/repo/snapshot/_restore - { - "indices": ".*", - "ignore_unavailable": true, - "include_global_state": false, - "include_aliases": false, - "rename_pattern": ".(.+)", - "rename_replacement": "restored_security_$1" - } - ``` - - * **Restore an individual internal index** - - ::::{warning} - When restoring internal indices, ensure that the `include_aliases` parameter is set to `false`. Not doing so will make Kibana inaccessible. If you do run the restore without `include_aliases`, the restored index can be deleted or the alias reference to it can be removed. This will have to be done from either the API console or a curl command as Kibana will not be accessible. - :::: - - - Run the following API call to restore one internal index from a snapshot to the cluster: - - ```sh - POST /_snapshot/repo/snapshot/_restore - { - "indices": ".kibana", - "ignore_unavailable": true, - "include_global_state": false, - "include_aliases": false, - "rename_pattern": ".(.+)", - "rename_replacement": "restored_security_$1" - } - ``` - - Next, the restored index needs to be reindexed into the internal index, as shown: - - ```sh - POST _reindex - { - "source": { - "index": "restored_kibana" - }, - "dest": { - "index": ".kibana" - } - } - ``` - - -Your internal Elasticsearch index or indices should now be available in your new Elasticsearch cluster. Once verified, the `restored_*` indices are safe to delete. diff --git a/deploy-manage/deploy/elastic-cloud/ech-migrate-data2.md b/deploy-manage/deploy/elastic-cloud/ech-migrate-data2.md deleted file mode 100644 index 1cff3803b8..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-migrate-data2.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrate-data2.html ---- - -# Migrate your Elasticsearch data [ech-migrate-data2] - -You might have switched to Elasticsearch Add-On for Heroku for any number of reasons and you’re likely wondering how to get your existing Elasticsearch data into your new infrastructure. Along with easily creating as many new deployments with Elasticsearch clusters that you need, you have several options for moving your data over. Choose the option that works best for you: - -* Index your data from the original source, which is the simplest method and provides the greatest flexibility for the Elasticsearch version and ingestion method. -* Reindex from a remote cluster, which rebuilds the index from scratch. -* Restore from a snapshot, which copies the existing indices. - -One of the many advantages of Elasticsearch Add-On for Heroku is that you can spin up a deployment quickly, try out something, and then delete it if you don’t like it. This flexibility provides the freedom to experiment while your existing production cluster continues to work. - - -## Before you begin [echbefore_you_begin_3] - -Depending on which option that you choose, you might have limitations or need to do some preparation beforehand. - -Indexing from the source -: The new cluster must be the same size as your old one, or larger, to accommodate the data. - -Reindex from a remote cluster -: The new cluster must be the same size as your old one, or larger, to accommodate the data. Depending on your security settings for your old cluster, you might need to temporarily allow TCP traffic on port 9243 for this procedure. - -Restore from a snapshot -: The new cluster must be the same size as your old one, or larger, to accommodate the data. The new cluster must also be an Elasticsearch version that is compatible with the old cluster (check [Elasticsearch snapshot version compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-restore-version-compatibility) for details). If you have not already done so, you will need to [set up snapshots for your old cluster](/deploy-manage/tools/snapshot-and-restore/self-managed.md) using a repository that can be accessed from the new cluster. - -Migrating internal Elasticsearch indices -: If you are migrating internal Elasticsearch indices from another cluster, specifically the `.kibana` index or the `.security` index, there are two options: - - * Use the steps on this page to reindex the internal indices from a remote cluster. The steps for reindexing internal indices and regular, data indices are the same. - * Check [Migrating internal indices](../../../manage-data/migrate/migrate-internal-indices.md) to restore the internal Elasticsearch indices from a snapshot. - - -::::{warning} -Before you migrate your Elasticsearch data, [define your index mappings](/manage-data/data-store/mapping.md) on the new cluster. Index mappings are unable to migrate during reindex operations. -:::: - - - -## Index from the source [ech-index-source] - -If you still have access to the original data source, outside of your old Elasticsearch cluster, you can load the data from there. This might be the simplest option, allowing you to choose the Elasticsearch version and take advantage of the latest features. You have the option to use any ingestion method that you want—​Logstash, Beats, the Elasticsearch clients, or whatever works best for you. - -If the original source isn’t available or has other issues that make it non-viable, there are still two more migration options, getting the data from a remote cluster or restoring from a snapshot. - - -## Reindex from a remote cluster [ech-reindex-remote] - -Through the Elasticsearch reindex API, you can connect your new Elasticsearch Add-On for Heroku deployment remotely to your old Elasticsearch cluster. This pulls the data from your old cluster and indexes it into your new one. Reindexing essentially rebuilds the index from scratch and it can be more resource intensive to run. - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. Select a deployment or create one. -3. If the old Elasticsearch cluster is on a remote host (any type of host accessible over the internet), you need to make sure that the host can be accessed. Access is determined by the Elasticsearch `reindex.remote.whitelist` user setting. - - Domains matching the pattern `["*.io:*", "*.com:*"]` are allowed by default, so if your remote host URL matches that pattern you do not need to explicitly define `reindex.remote.whitelist`. - - Otherwise, if your remote endpoint is not covered by the default settings, adjust the setting to add the remote Elasticsearch cluster as an allowed host: - - 1. From your deployment menu, go to the **Edit** page. - 2. In the **Elasticsearch** section, select **Manage user settings and extensions**. For deployments with existing user settings, you may have to expand the **Edit elasticsearch.yml** caret for each node type instead. - 3. Add the following `reindex.remote.whitelist: [REMOTE_HOST:PORT]` user setting, where `REMOTE_HOST` is a pattern matching the URL for the remote Elasticsearch host that you are reindexing from, and PORT is the host port number. Do not include the `https://` prefix. - - Note that if you override the parameter it replaces the defaults: `["*.io:*", "*.com:*"]`. If you still want these patterns to be allowed you need to specify them explicitly in the value. - - For example: - - `reindex.remote.whitelist: ["*.us-east-1.aws.found.io:9243", "*.com:*"]` - - 4. Save your changes. - -4. From the **API Console** or in the Kibana Console app, create the destination index on Elasticsearch Add-On for Heroku. -5. Copy the index from the remote cluster: - - ```sh - POST _reindex - { - "source": { - "remote": { - "host": "https://REMOTE_ELASTICSEARCH_ENDPOINT:PORT", - "username": "USER", - "password": "PASSWORD" - }, - "index": "INDEX_NAME", - "query": { - "match_all": {} - } - }, - "dest": { - "index": "INDEX_NAME" - } - } - ``` - -6. Verify that the new index is present: - - ```sh - GET INDEX-NAME/_search?pretty - ``` - -7. You can remove the reindex.remote.whitelist user setting that you added previously. - - -## Restore from a snapshot [ech-restore-snapshots] - -If you cannot connect to a remote index for whatever reason, such as if it’s in a non-working state, you can try restoring from the most recent working snapshot. - -1. On your old Elasticsearch cluster, choose an option to get the name of your snapshot repository bucket: - - ```sh - GET /_snapshot - GET /_snapshot/_all - ``` - -2. Get the snapshot name: - - ```sh - GET /_snapshot/NEW-REPOSITORY-NAME/_all - ``` - - The output for each entry provides a `"snapshot":` value which is the snapshot name. - - ```json - { - "snapshots": [ - { - "snapshot": "scheduled-1527616008-instance-0000000004", - ... - }, - ... - ] - } - ``` - -3. From the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) of the **new** Elasticsearch cluster, add the snapshot repository. For details, check our guidelines for [Amazon Web Services (AWS) Storage](../../tools/snapshot-and-restore/ec-aws-custom-repository.md), [Google Cloud Storage (GCS)](../../tools/snapshot-and-restore/ec-gcs-snapshotting.md), or [Azure Blob Storage](../../tools/snapshot-and-restore/ec-azure-snapshotting.md). - - ::::{important} - If you’re migrating [searchable snapshots](../../tools/snapshot-and-restore/searchable-snapshots.md), the repository name must be identical in the source and destination clusters. - :::: - - - ::::{important} - If source cluster is still writing to the repository, you need to set the destination cluster’s repository connection to `readonly:true` to avoid data corruption. Refer to [backup a repository](../../tools/snapshot-and-restore/self-managed.md#snapshots-repository-backup) for details. - :::: - -4. Start the Restore process. - - 1. Open Kibana and go to **Management** > **Snapshot and Restore**. - 2. Under the **Snapshots** tab, you can find the available snapshots from your newly added snapshot repository. Select any snapshot to view its details, and from there you can choose to restore it. - 3. Select **Restore**. - 4. Select the indices you wish to restore. - 5. Configure any additional index settings. - 6. Select **Restore snapshot** to begin the process. - -5. Verify that the new index is restored in your Elasticsearch Add-On for Heroku deployment with this query: - - ```sh - GET INDEX_NAME/_search?pretty - ``` - - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-reference-hardware.md b/deploy-manage/deploy/elastic-cloud/ech-reference-hardware.md deleted file mode 100644 index 75c00e5e73..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-reference-hardware.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-reference-hardware.html ---- - -# Elasticsearch Add-On for Heroku hardware [ech-reference-hardware] - -:::{image} /deploy-manage/images/cloud-heroku-ec-cloud-platform-hardware.png -:alt: A banner showing a plane trailing several stylized UI sliders superimposed over cloud hardware -::: - -Use this information to better understand how Elasticsearch Add-On for Heroku instance configurations (for example `azure.es.datahot.ddv4`, `gcp.es.datahot.n2.68x10x45`, or `aws.es.datahot.c6gd`) relate to the underlying cloud provider hardware that we use when you create your deployment. - - -## Instance configurations [ech-getting-started-configurations] - -Deployments use a range of virtualized hardware resources from a cloud provider, such as Amazon EC2 (AWS), Google Compute Platform (GCP) or Microsoft Azure. Instance configurations enable the products and features of the Elastic Stack to run on suitable resources that support their intended purpose. For example, if you have a logging use case that benefits from large amounts of slower but more cost-efficient storage space, you can use large spindle drives rather than more expensive SSD storage. Each instance configuration provides a combination of CPU resources, memory, and storage, all of which you can scale from small to very large. - -::::{note} -All instances, regardless of the region or provider, are set to UTC timezone. -:::: - - -To understand the naming convention of instance configuration per cloud provider, refer to [Azure instance configurations](ech-azure-instance-configuration.md), [GCP instance configurations](ech-gcp-instance-configuration.md) and [AWS instance configurations](ech-aws-instance-configuration.md). - -::::{tip} -Instance configurations are an Elasticsearch Add-On for Heroku abstraction of virtualized resources from the provider, but you might recognize the underlying hardware they build on in the instance configuration name. We use *instance types* on AWS and Azure, and *custom machine types* on GCP. Elasticsearch Add-On for Heroku instance configurations are not the same as AWS instance types. -:::: - - - - - - - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-restrictions.md b/deploy-manage/deploy/elastic-cloud/ech-restrictions.md deleted file mode 100644 index f9e47b4422..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-restrictions.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-restrictions.html ---- - -# Restrictions and known problems [ech-restrictions] - -When using Elasticsearch Add-On for Heroku, there are some limitations you should be aware of: - -* [Elasticsearch Add-On for Heroku](#ech-restrictions-heroku) -* [Security](#ech-restrictions-security) -* [Elasticsearch and Kibana plugins](#ech-restrictions-plugins) -* [Kibana](#ech-restrictions-kibana) -* [APM Agent central configuration with Private Link or traffic filters](#ech-restrictions-apm-traffic-filters) -* [Fleet with Private Link or traffic filters](#ech-restrictions-fleet-traffic-filters) -* [Enterprise Search in Kibana](#ech-restrictions-enterprise-search-kibana-integration-traffic-filters) -* [Restoring a snapshot across deployments](#ech-snapshot-restore-enterprise-search-kibana-across-deployments) -* [Migrate Fleet-managed {{agents}} across deployments by restoring a snapshot](#ech-migrate-elastic-agent) -* [Regions and Availability Zones](#ech-regions-and-availability-zone) -* [Known problems](#ech-known-problems) - -For limitations related to logging and monitoring, check the [Restrictions and limitations](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) section of the logging and monitoring page. - -Occasionally, we also publish information about [Known problems](#ech-known-problems) with our Elasticsearch Add-On for Heroku or the Elastic Stack. - -To learn more about the features that are supported by Elasticsearch Add-On for Heroku, check [Elastic Cloud Subscriptions](https://www.elastic.co/cloud/elasticsearch-service/subscriptions?page=docs&placement=docs-body). - - -## Elasticsearch Add-On for Heroku [ech-restrictions-heroku] - -Not all features of {{ecloud}} are available to Heroku users. Specifically, you cannot create additional deployments or use different deployment templates. - -Generally, if a feature is shown as available in the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body), you can use it. - - -## Security [ech-restrictions-security] - -* File and LDAP realms cannot be used. The Native realm is enabled, but the realm configuration itself is fixed in {{ecloud}}. Alternatively, authentication protocols such as SAML, OpenID Connect, or Kerberos can be used. -* Client certificates, such as PKI certificates, are not supported. -* IPv6 is not supported. - - -## Transport client [ech-restrictions-transport-client] - -* The transport client is not considered thread safe in a cloud environment. We recommend that you use the Java REST client instead. This restriction relates to the fact that your deployments hosted on Elasticsearch Add-On for Heroku are behind proxies, which prevent the transport client from communicating directly with Elasticsearch clusters. -* The transport client is not supported over [private link connections](../../security/aws-privatelink-traffic-filters.md). Use the Java REST client instead, or connect over the public internet. -* The transport client does not work with Elasticsearch clusters at version 7.6 and later that are hosted on Cloud. Transport client continues to work with Elasticsearch clusters at version 7.5 and earlier. Note that the transport client was deprecated with version 7.0 and will be removed with 8.0. - - -## Elasticsearch and Kibana plugins [ech-restrictions-plugins] - -* Kibana plugins are not supported. -* Elasticsearch plugins, are not enabled by default for security purposes. Please reach out to support if you would like to enable Elasticsearch plugins support on your account. -* Some Elasticsearch plugins do not apply to Elasticsearch Add-On for Heroku. For example, you won’t ever need to change discovery, as Elasticsearch Add-On for Heroku handles how nodes discover one another. -* In Elasticsearch 5.0 and later, site plugins are no longer supported. This change does not affect the site plugins Elasticsearch Add-On for Heroku might provide out of the box, such as Kopf or Head, since these site plugins are serviced by our proxies and not Elasticsearch itself. -* In Elasticsearch 5.0 and later, site plugins such as Kopf and Paramedic are no longer provided. We recommend that you use our [cluster performance metrics](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md), [X-Pack monitoring features](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) and Kibana’s (6.3+) [Index Management UI](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-mgmt.html) if you want more detailed information or perform index management actions. - - -## Private Link and SSO to Kibana URLs [ech-restrictions-traffic-filters-kibana-sso] - -Currently you can’t use SSO to login directly from {{ecloud}} into Kibana endpoints that are protected by Private Link traffic filters. However, you can still SSO into Private Link protected Kibana endpoints individually using the [SAML](../../users-roles/cluster-or-deployment-auth/saml.md) or [OIDC](../../users-roles/cluster-or-deployment-auth/openid-connect.md) protocol from your own identity provider, just not through the {{ecloud}} console. Stack level authentication using the {{es}} username and password should also work with `{{kibana-id}}.{vpce|privatelink|psc}.domain` URLs. - - -## PDF report generation using Alerts or Watcher webhooks [ech-restrictions-traffic-filters-watcher] - -* PDF report automatic generation via Alerts is not possible on Elastic Cloud. -* PDF report generation isn’t possible for deployments running on Elastic stack version 8.7.0 or before that are protected by traffic filters. This limitation doesn’t apply to public webhooks such as Slack, PagerDuty, and email. For deployments running on Elastic stack version 8.7.1 and beyond, [PDF report automatic generation via Watcher webhook](../../../explore-analyze/report-and-share/automating-report-generation.md#use-watcher) is possible using the `xpack.notification.webhook.additional_token_enabled` configuration setting to bypass traffic filters. - - -## Kibana [ech-restrictions-kibana] - -* The maximum size of a single {{kib}} instance is 8GB. This means, {{kib}} instances can be scaled up to 8GB before they are scaled out. For example, when creating a deployment with a {{kib}} instance of size 16GB, then 2x8GB instances are created. If you face performance issues with {{kib}} PNG or PDF reports, the recommendations are to create multiple, smaller dashboards to export the data, or to use a third party browser extension for exporting the dashboard in the format you need. -* Running an external Kibana in parallel to Elasticsearch Add-On for Heroku’s Kibana instances may cause errors, for example [`Unable to decrypt attribute`](../../../explore-analyze/alerts-cases/alerts/alerting-common-issues.md#rule-cannot-decrypt-api-key), due to a mismatched [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#security-encrypted-saved-objects-settings) as Elasticsearch Add-On for Heroku does not [allow users to set](edit-stack-settings.md) nor expose this value. While workarounds are possible, this is not officially supported nor generally recommended. - - -## APM Agent central configuration with PrivateLink or traffic filters [ech-restrictions-apm-traffic-filters] - -If you are using APM 7.9.0 or older: - -* You cannot use [APM Agent central configuration](/solutions/observability/apps/apm-agent-central-configuration.md) if your deployment is secured by [traffic filters](../../security/traffic-filtering.md). -* If you access your APM deployment over [PrivateLink](../../security/aws-privatelink-traffic-filters.md), to use APM Agent central configuration you need to allow access to the APM deployment over public internet. - - -## Fleet with PrivateLink or traffic filters [ech-restrictions-fleet-traffic-filters] - -* You cannot use Fleet 7.13.x if your deployment is secured by [traffic filters](../../security/traffic-filtering.md). Fleet 7.14.0 and later works with traffic filters (both Private Link and IP filters). -* If you are using Fleet 8.12+, using a remote {{es}} output with a target cluster that has [traffic filters](../../security/traffic-filtering.md) enabled is not currently supported. - - -## Enterprise Search in Kibana [ech-restrictions-enterprise-search-kibana-integration-traffic-filters] - -:::{important} -Enterprise Search is not available in {{stack}} 9.0+. -::: - -Enterprise Search’s management interface in Kibana does not work with traffic filters with 8.3.1 and older, it will return an `Insufficient permissions` (403 Forbidden) error. In Kibana 8.3.2, 8.4.0 and higher, the Enterprise Search management interface works with traffic filters. - - -## Restoring a snapshot across deployments [ech-snapshot-restore-enterprise-search-kibana-across-deployments] - -Kibana and Enterprise Search do not currently support restoring a snapshot of their indices across Elastic Cloud deployments. - -* [Kibana uses encryption keys](/deploy-manage/security/secure-your-cluster-deployment.md#security-configure-settings) in various places, ranging from encrypting data in some areas of reporting, alerts, actions, connector tokens, ingest outputs used in Fleet and Synthetics monitoring to user sessions. -* [Enterprise Search uses encryption keys](https://www.elastic.co/guide/en/enterprise-search/current/encryption-keys.html) when storing content source synchronization credentials, API tokens and other sensitive information. -* Currently, there is not a way to retrieve the values of Kibana and Enterprise Search encryption keys, or set them in the target deployment before restoring a snapshot. As a result, once a snapshot is restored, Kibana and Enterprise Search will not be able to decrypt the data required for some Kibana and Enterprise Search features to function properly in the target deployment. -* If you have already restored a snapshot across deployments and now have broken Kibana saved objects or Enterprise Search features in the target deployment, you will have to recreate all broken configurations and objects, or create a new setup in the target deployment instead of using snapshot restore. - -A snapshot taken using the default `found-snapshots` repository can only be restored to deployments in the same region. If you need to restore snapshots across regions, create the destination deployment, connect to the [custom repository](../../tools/snapshot-and-restore/elastic-cloud-hosted.md), and then [restore from a snapshot](../../tools/snapshot-and-restore/restore-snapshot.md). - -When restoring from a deployment that’s using searchable snapshots, you must not delete the snapshots in the source deployment even after they are successfully restored in the destination deployment. - - -## Migrate Fleet-managed {{agents}} across deployments by restoring a snapshot [ech-migrate-elastic-agent] - -There are situations where you may need or want to move your installed {{agents}} from being managed in one deployment to being managed in another deployment. - -In {{ecloud}}, you can migrate your {{agents}} by taking a snapshot of your source deployment, and restoring it on a target deployment. - -To make a seamless migration, after restoring from a snapshot there are some additional steps required, such as updating settings and resetting the agent policy. Check [Migrate Elastic Agents](/reference/ingestion-tools/fleet/migrate-elastic-agent.md) for details. - - -## Regions and Availability Zones [ech-regions-and-availability-zone] - -* The AWS `us-west-1` region is limited to two availability zones for ES data nodes and one (tiebreaker only) virtual zone (as depicted by the `-z` in the AZ (`us-west-1z`). Deployment creation with three availability zones for Elasticsearch data nodes for hot, warm, and cold tiers is not possible. This includes scaling an existing deployment with one or two AZs to three availability zones. The virtual zone `us-west-1z` can only hold an Elasticsearch tiebreaker node (no data nodes). The workaround is to use a different AWS US region that allows three availability zones, or to scale existing nodes up within the two availability zones. -* The AWS `eu-central-2` region is limited to two availability zones for CPU Optimized (ARM) Hardware profile ES data node and warm/cold tier. Deployment creation with three availability zones for Elasticsearch data nodes for hot (for CPU Optimized (ARM) profile), warm and cold tiers is not possible. This includes scaling an existing deployment with one or two AZs to three availability zones. The workaround is to use a different AWS region that allows three availability zones, or to scale existing nodes up within the two availability zones. - - -## Known problems [ech-known-problems] - -* There is a known problem affecting clusters with versions 7.7.0 and 7.7.1 due to [a bug in Elasticsearch](https://github.com/elastic/elasticsearch/issues/56739). Although rare, this bug can prevent you from running plans. If this occurs we recommend that you retry the plan, and if that fails please contact support to get your plan through. Because of this bug we recommend you to upgrade to version 7.8 and higher, where the problem has already been addressed. -* A known issue can prevent direct rolling upgrades from Elasticsearch version 5.6.10 to version 6.3.0. As a workaround, we have removed version 6.3.0 from the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) for new cluster deployments and for upgrading existing ones. If you are affected by this issue, check [Rolling upgrades from 5.6.x to 6.3.0 fails with "java.lang.IllegalStateException: commit doesn’t contain history uuid"](https://elastic.my.salesforce.com/articles/Support_Article/Rolling-upgrades-to-6-3-0-from-5-x-fails-with-java-lang-IllegalStateException-commit-doesn-t-contain-history-uuid?popup=false&id=kA0610000005JFG) in our Elastic Support Portal. If these steps do not work or you do not have access to the Support Portal, you can contact `support@elastic.co`. - - -## Repository Analysis API is unavailable in Elastic Cloud [ech-repository-analyis-unavailable] - -* The Elasticsearch [Repository analysis API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-repository-analyze) is not available in {{ecloud}} due to deployments defaulting to having [operator privileges](../../users-roles/cluster-or-deployment-auth/operator-privileges.md) enabled that prevent non-operator privileged users from using it along with a number of other APIs. diff --git a/deploy-manage/deploy/elastic-cloud/ech-service-status.md b/deploy-manage/deploy/elastic-cloud/ech-service-status.md deleted file mode 100644 index 9a8718c661..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-service-status.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-service-status.html ---- - -# Service status [ech-service-status] - -Elasticsearch Add-On for Heroku is a hosted service for the Elastic Stack that runs on different cloud platforms, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Like any service, it might undergo availability changes from time to time. When availability changes, Elastic makes sure to provide you with a current service status. - -To check current and past service availability, go to [Cloud Status](https://cloud-status.elastic.co/) page. - - -## Subscribe to updates [echsubscribe_to_updates] - -Don’t want to check the service status page manually? You can get notified about changes to the service status automatically. - -To receive service status updates: - -1. Go to the [Cloud Status](https://cloud-status.elastic.co/) page and select **SUBSCRIBE TO UPDATES**. -2. Select one of the following methods to be notified of status updates: - - * Email - * Twitter - * Atom and RSS feeds - - -After you subscribe to updates, you are notified whenever a service status update is posted. - - - diff --git a/deploy-manage/deploy/elastic-cloud/ech-version-policy.md b/deploy-manage/deploy/elastic-cloud/ech-version-policy.md deleted file mode 100644 index 79b75d2803..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-version-policy.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-version-policy.html ---- - -# Version policy [ech-version-policy] - -This section describes our version policy for Elasticsearch Add-On for Heroku, including: - -* [What Elastic Stack versions are available](#ech-version-policy-available) -* [When we make new Elastic Stack versions available](#ech-version-policy-new) -* [When we might force an upgrade or restart to keep your cluster safe](#ech-version-policy-critical) -* [What release candidates and cutting edge builds we make available](#ech-release-builds) -* [What happens when a version reaches its end-of-life (EOL)](#ech-version-policy-eol) - - -## Available Elastic Stack versions [ech-version-policy-available] - -Elastic Stack uses a versions code that is constructed of three numbers separated by dots: the leftmost number is the number of the major release, the middle number is the number of the minor release and the rightmost number is the number of the maintenance release (e.g., 8.3.2 means major release 8, minor release 3 and maintenance release 2). - -You might sometimes notice additional versions listed in the user interface beyond the versions we currently support and maintain, such as [release candidate builds](#ech-release-builds) and older versions. If a version is listed in the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body), it can be deployed. - - -## New Elastic Stack versions [ech-version-policy-new] - -Whenever a new Elastic Stack version is released, we do our best to provide the new version on our hosted service at the same time. We send you an email and add a notice to the console, recommending an upgrade. You’ll need to decide whether to upgrade to the new version with new features and bug fixes or to stay with a version you know works for you a while longer. - -There can be [breaking changes](elasticsearch://release-notes/breaking-changes.md) in some new versions of Elasticsearch that break what used to work in older versions. Before upgrading, you’ll want to check if the new version introduces any changes that might affect your applications. A breaking change might be a function that was previously deprecated and that has been removed in the latest version, for example. If you have an application that depends on the removed function, the application will need to be updated to continue working with the new version of Elasticsearch. - -To learn more about upgrading to newer versions of the Elastic Stack on our hosted service, check [Upgrade Versions](../../upgrade/deployment-or-cluster.md). - - -## Upgrades or restart for critical issues [ech-version-policy-critical] - -We reserve the right to force upgrade or restart a cluster immediately and without notice in advance if there is a critical security or stability issue. Such upgrades happen only within minor versions. - -A forced upgrade or restart might become necessary in a situation that: - -* Bypasses Shield, where knowing only the cluster endpoint is sufficient to gain access to data. -* Disrupts our ability to effectively manage a cluster in disaster scenarios -* Impairs stability to the point where we cannot guarantee cluster node or data integrity -* Impairs or risks impairing our infrastructure - - -## Release candidates and cutting-edge releases [ech-release-builds] - -Interested in kicking the tires of Elasticsearch releases at the cutting edge? We sometimes make release candidate builds and other cutting-edge releases available in Elasticsearch Add-On for Heroku for you to try out. - -::::{warning} -Remember that cutting-edge releases are used to test new function fully. These releases might still have issues and might be less stable than the GA version. There’s also no guaranteed upgrade path to the GA version when it becomes available. -:::: - - -If you’re interested in trying out one of these cutting-edge releases, we don’t recommended upgrading an existing deployment directly. Instead, use a copy of your existing data with a test deployment, first. - -Cutting-edge releases do not remain available forever. Once the GA version of Elasticsearch is released, your deployment needs to be removed after a grace period. We cannot guarantee that you will be able to upgrade to the GA version when it becomes available. - - -## Version Policy and Product End of Life [ech-version-policy-eol] - -For {{ecloud}}, we follow the [Elastic Version Maintenance and Support Policy](https://www.elastic.co/support/eol), which defines the support and maintenance policy of the Elastic Stack. diff --git a/deploy-manage/deploy/elastic-cloud/ech-whats-new.md b/deploy-manage/deploy/elastic-cloud/ech-whats-new.md deleted file mode 100644 index 1973c11952..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-whats-new.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-whats-new.html ---- - -# What's new with the Elastic Stack [ech-whats-new] - -As soon as the latest Elastic Stack version is released, we make it available to you. - -From the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body), you can upgrade your existing deployments to the latest versions of the Elastic Stack. To learn more about the best practices to use when upgrading, refer to [Upgrade versions](../../upgrade/deployment-or-cluster.md). - -Check our [Version policy](ech-version-policy.md) to learn about when and how new Elastic Stack versions are made available. - -Check the Release Notes to get the recent updates for each product. - -Elasticsearch - -* [Elasticsearch 8.x Release Notes](elasticsearch://release-notes/index.md) -* [Elasticsearch 7.x Release Notes](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/es-release-notes.html) -* [Elasticsearch 6.x Release Notes](https://www.elastic.co/guide/en/elasticsearch/reference/6.8/es-release-notes.html) -* [Elasticsearch 5.x Release Notes](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/es-release-notes.html) - -Kibana - -* [Kibana 8.x Release Notes](kibana://release-notes/index.md) -* [Kibana 7.x Release Notes](https://www.elastic.co/guide/en/kibana/7.17/release-notes.html) -* [Kibana 6.x Release Notes](https://www.elastic.co/guide/en/kibana/6.8/release-notes.html) -* [Kibana 5.x Release Notes](https://www.elastic.co/guide/en/kibana/5.6/release-notes.html) - -APM - -* [APM Release Notes](https://www.elastic.co/guide/en/apm/guide/current/release-notes.html) - -Enterprise Search - -:::{important} -Enterprise Search is not available in {{stack}} 9.0+. -::: - -* [Enterprise Search Release Notes](https://www.elastic.co/guide/en/enterprise-search/current/changelog.html) - diff --git a/deploy-manage/deploy/elastic-cloud/ech-working-with-elasticsearch.md b/deploy-manage/deploy/elastic-cloud/ech-working-with-elasticsearch.md deleted file mode 100644 index f05054c598..0000000000 --- a/deploy-manage/deploy/elastic-cloud/ech-working-with-elasticsearch.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/ech-working-with-elasticsearch.html ---- - -# Manage data from the command line [ech-working-with-elasticsearch] - -Learn how to index, update, retrieve, search, and delete documents in an {{es}} cluster from the command line. - -::::{tip} -If you are looking for a user interface for {{es}} and your data, head on over to [Kibana](ech-access-kibana.md)! Not only are there amazing visualization and index management tools, Kibana includes realistic sample data sets to play with so that you can get to know what you *could* do with your data. -:::: - - - -## Before you begin [echbefore_you_begin_2] - -To find out what the ELASTICSEARCH_URL is for your {{es}} cluster, grep on the output of the `heroku config` command for your app: - -```bash -heroku config --app MY_APP | grep ELASTICSEARCH_URL -ELASTICSEARCH_URL: https://74f176887fdef36bb51e6e37nnnnnnnn.us-east-1.aws.found.io -``` - -These examples use the `elastic` user. If you didn’t copy down the password for the `elastic` user, you can [reset the password](../../users-roles/cluster-or-deployment-auth/built-in-users.md). - -To use these examples, you also need to have the [curl](http://curl.haxx.se/) command installed. - - -## Indexing [echindexing] - -To index a document into {{es}}, `POST` your document: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc -XPOST -H 'Content-Type: application/json' -d '{ - "title": "One", "tags": ["ruby"] -}' -``` - -To show that the operation worked, {{es}} returns a JSON response that looks like `{"_index":"my_index","_type":"_doc","_id":"0KNPhW4BnhCSymaq_3SI","_version":1,"result":"created","_shards":{"total":2,"successful":2,"failed":0},"_seq_no":0,"_primary_term":1}`. - -In this example, the index `my_index` is created dynamically when the first document is inserted into it. All documents in {{es}} have a `type` and an `id`, which is echoed as `"_type":"_doc"` and `_id":"0KNPhW4BnhCSymaq_3SI` in the JSON response. If no ID is specified during indexing, a random `id` is generated. - - -### Bulk indexing [echbulk_indexing] - -To achieve the best possible performance, use the bulk API. - -To index some additional documents with the bulk API: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/_bulk -XPOST -H 'Content-Type: application/json' -d ' -{"index": {}} -{"title": "Two", "tags": ["ruby", "python"] } -{"index": {}} -{"title": "Three", "tags": ["java"] } -{"index": {}} -{"title": "Four", "tags": ["ruby", "php"] } -' -``` - -Elasticsearch returns a JSON response similar to this one: - -```json -{"took":694,"errors":false,"items":[{"index":{"_index":"my_index","_type":"_doc","_id":"0aNqhW4BnhCSymaqFHQn","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":0,"_primary_term":1,"status":201}},{"index":{"_index":"my_index","_type":"_doc","_id":"0qNqhW4BnhCSymaqFHQn","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":1,"_primary_term":1,"status":201}},{"index":{"_index":"my_index","_type":"_doc","_id":"06NqhW4BnhCSymaqFHQn","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":2,"_primary_term":1,"status":201}}]} -``` - - -## Updating [echupdating] - -To update an existing document in {{es}}, `POST` the updated document to `http://ELASTICSEARCH_URL/my_index/_doc/ID`, where the ID is the `_id` of the document. - -For example, to update the last document indexed from the previous example with `"_id":"06NqhW4BnhCSymaqFHQn"`: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/06NqhW4BnhCSymaqFHQn -XPOST -H 'Content-Type: application/json' -d '{ - "title": "Four updated", "tags": ["ruby", "php", "python"] -}' -``` - -The JSON response shows that the version counter for the document got incremented to `_version":2` to reflect the update. - - -## Retrieving documents [echretrieving_documents] - -To take a look at a specific document you indexed, here the last document we updated with the ID `0KNPhW4BnhCSymaq_3SI`: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/06NqhW4BnhCSymaqFHQn -``` - -This request didn’t include `GET`, as the method is implied if you don’t specify anything else. If the document you are looking for exists, {{es}} returns `found":true` along with the document as part of the JSON response. Otherwise, the JSON response contains `"found":false`. - - -## Searching [echsearching] - -You issue search requests for documents with one of these {{es}} endpoints: - -```bash -https://ELASTICSEARCH_URL/_search -https://ELASTICSEARCH_URL/INDEX_NAME/_search -``` - -Either a `GET` or a `POST` request with some URI search parameters works, or omit the method to default to `GET` request: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/_search?q=title:T* -``` - -For an explanation of the allowed parameters, check [URI Search](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search). - -To make {{es}} return a more human readable JSON response, add `?pretty=true` to the request: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/_search?pretty=true -H 'Content-Type: application/json' -d '{ - "query": { - "query_string": {"query": "*"} - } -}' -``` - -For performance reasons, `?pretty=true` is not recommended in production. You can verify the performance difference yourself by checking the `took` field in the JSON response which tells you how long Elasticsearch took to evaluate the search in milliseconds. When we tested these examples ourselves, the difference was `"took" : 4` against `"took" : 18`, a substantial difference. - -For a full explanation of how the request body is structured, check [Elasticsearch Request Body documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html). You can also execute multiple queries in one request with the [Multi Search API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-msearch). - - -## Deleting [echdeleting] - -You delete documents from {{es}} by sending `DELETE` requests. - -To delete a single document by ID from an earlier example: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc/06NqhW4BnhCSymaqFHQn -XDELETE -``` - -To delete a whole index, here `my_index`: - -```bash -curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index -XDELETE -``` - -The JSON response returns `{"acknowledged":true}` to indicate that the index deletion was a success. - diff --git a/deploy-manage/deploy/elastic-cloud/echservice_status_api.md b/deploy-manage/deploy/elastic-cloud/echservice_status_api.md deleted file mode 100644 index 2161122fe2..0000000000 --- a/deploy-manage/deploy/elastic-cloud/echservice_status_api.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/echservice_status_api.html ---- - -# Service Status API [echservice_status_api] - -If you want a more programmatical method of ingesting our Service Status updates, we also expose some API endpoints that you can avail of. - -For more information and to get started, go to our [Service Status API](https://status.elastic.co/api/) page. - diff --git a/deploy-manage/deploy/elastic-cloud/echsubscribe_to_individual_regionscomponents.md b/deploy-manage/deploy/elastic-cloud/echsubscribe_to_individual_regionscomponents.md deleted file mode 100644 index b8f072d569..0000000000 --- a/deploy-manage/deploy/elastic-cloud/echsubscribe_to_individual_regionscomponents.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -mapped_pages: - - https://www.elastic.co/guide/en/cloud-heroku/current/echsubscribe_to_individual_regionscomponents.html ---- - -# Subscribe to Individual Regions/Components [echsubscribe_to_individual_regionscomponents] - -If you want to know about specific status updates, rather than all of them, you can adjust your preferences by using the following steps (this is used to both sign up a new email and adjust an existing subscription) . Go to the [Cloud Status](https://cloud-status.elastic.co/) page and select **SUBSCRIBE TO UPDATES**. . Enter your email address and click **SUBSCRIBE VIA EMAIL**. . You will be brought to a page with a list of Components - -Here you can either select all, select none, and customise as you require. This way, you’ll only be notified about the status updates that are important to you. - diff --git a/deploy-manage/deploy/elastic-cloud/ech-getting-started-accessing.md b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-accessing.md similarity index 84% rename from deploy-manage/deploy/elastic-cloud/ech-getting-started-accessing.md rename to deploy-manage/deploy/elastic-cloud/heroku-getting-started-accessing.md index 08b70d28b6..286665c301 100644 --- a/deploy-manage/deploy/elastic-cloud/ech-getting-started-accessing.md +++ b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-accessing.md @@ -1,6 +1,9 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-accessing.html +applies_to: + deployment: + ess: --- # Access the console [ech-getting-started-accessing] @@ -18,6 +21,7 @@ heroku addons:open foundelasticsearch --app MY_APP Opening https://addons-sso.heroku.com/apps/e286f875-cbdb-47a9-b445-e94bnnnnnnnn/addons/9b883e93-3db3-4491-b620-c3dfnnnnnnnn... ``` -Alternatively, you can access the console by visiting the [Heroku Dashboard](https://dashboard.heroku.com/), selecting your app, and opening the Elasticsearch link. +Alternatively, you can access the console by visiting the [Heroku Dashboard](https://dashboard.heroku.com/), selecting your app, and opening the {{es}} link. +To learn how to access {{kib}}, refer to [](/deploy-manage/deploy/elastic-cloud/access-kibana.md). \ No newline at end of file diff --git a/deploy-manage/deploy/elastic-cloud/heroku-getting-started-installing.md b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-installing.md new file mode 100644 index 0000000000..42e47cdc3b --- /dev/null +++ b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-installing.md @@ -0,0 +1,57 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-installing.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-installing-version.html +applies_to: + deployment: + ess: +--- + +# Install the add-on [ech-getting-started-installing] + +These steps walk you through installing the {{heroku}} from the Heroku CLI. You can either install the latest default version of the add-on or you can install a specific version and include plugins at the same time. + + +## Before you begin [echbefore_you_begin] + +The installation steps in this section assume that you have a basic working knowledge of the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) and are familiar with using the command line. To work with the {{heroku}} from the command line, you need to have the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) already installed. + +If you prefer to install the add-on through your web browser, go to the [{{es}} add-on](https://elements.heroku.com/addons/foundelasticsearch) page in the Elements Marketplace, select **Install Elasticsearch**, pick the add-on plan you want, and select **Provision add-on**. + + +## Steps [echsteps] + +To install the latest add-on for `MY_APP` using the Heroku CLI: + +```bash +heroku addons:create foundelasticsearch --app MY_APP +``` + +After the {{heroku}} gets added, you can find the canonical URL you use to access your newly provisioned cluster in the configuration for the app. Look for the `FOUNDELASTICSEARCH_URL` setting when you grep on the output of the `heroku config` command: + +```bash +heroku config --app MY_APP | grep FOUNDELASTICSEARCH_URL +FOUNDELASTICSEARCH_URL: https://74f176887fdef36bb51e6e37nnnnnnnn.us-east-1.aws.found.io +``` + +## Install a specific version and plugins [ech-getting-started-installing-version] + +If you want your add-on to run a specific version of Elasticsearch, use the `--elasticsearch-version` parameter. We also provide many of the plugins that are available for Elasticsearch. You use the `--plugins` parameter to specify a comma-separated list of plugins that you want installed. + +To find which {{es}} versions and plugins are currently available, you can omit the version to default to the latest one and add plugins later on from the [{{heroku}} console](https://cloud.elastic.co?page=docs&placement=docs-body). To use your own custom plugins, you can upload and select these plugins in the console as well. + +For example: Install the add-on version {{stack-version}} and include the phonetic analysis plugin for MY_APP: + +```bash subs=true +heroku addons:create foundelasticsearch --elasticsearch-version {{stack-version}} --plugins analysis-phonetic --app MY_APP +``` + +After the add-on gets added, you can perform future version upgrades and plugin changes through the [console](heroku-getting-started-accessing.md). + +## Next steps + +- [](/deploy-manage/deploy/elastic-cloud/heroku-getting-started-accessing.md) +- [](/deploy-manage/deploy/elastic-cloud/heroku-working-with-elasticsearch.md) +- [](/deploy-manage/deploy/elastic-cloud/heroku.md#next-steps) + +To learn how to remove the add-on, refer to [](/deploy-manage/deploy/elastic-cloud/heroku-getting-started-removing.md). \ No newline at end of file diff --git a/deploy-manage/deploy/elastic-cloud/ech-getting-started-removing.md b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-removing.md similarity index 94% rename from deploy-manage/deploy/elastic-cloud/ech-getting-started-removing.md rename to deploy-manage/deploy/elastic-cloud/heroku-getting-started-removing.md index 857a86a295..207b10b5bf 100644 --- a/deploy-manage/deploy/elastic-cloud/ech-getting-started-removing.md +++ b/deploy-manage/deploy/elastic-cloud/heroku-getting-started-removing.md @@ -1,6 +1,9 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-removing.html +applies_to: + deployment: + ess: --- # Remove the add-on [ech-getting-started-removing] diff --git a/deploy-manage/deploy/elastic-cloud/ech-migrating.md b/deploy-manage/deploy/elastic-cloud/heroku-migrating.md similarity index 77% rename from deploy-manage/deploy/elastic-cloud/ech-migrating.md rename to deploy-manage/deploy/elastic-cloud/heroku-migrating.md index 2d1bbd1ed5..1edfd93057 100644 --- a/deploy-manage/deploy/elastic-cloud/ech-migrating.md +++ b/deploy-manage/deploy/elastic-cloud/heroku-migrating.md @@ -1,18 +1,21 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrating.html +applies_to: + deployment: + ess: --- # Migrate between plans [ech-migrating] -Plans for the Elasticsearch Add-On for Heroku differ based on: +Plans for the {{heroku}} differ based on: * How much memory and disk space are available * How many data centers your cluster is replicated across to achieve high availability -Available memory is an important factor for performance when sizing your Elasticsearch cluster, and replicating across multiple data centers is important for the resilience of production applications. +Available memory is an important factor for performance when sizing your {{es}} cluster, and replicating across multiple data centers is important for the resilience of production applications. -To learn more about what plans are available for Heroku users, check the [Elasticsearch add-on](https://elements.heroku.com/addons/foundelasticsearch) in the Elements Marketplace. +To learn more about what plans are available for Heroku users, check the [{{es}} add-on](https://elements.heroku.com/addons/foundelasticsearch) in the Elements Marketplace. You should time the migration to a new plan to ensure proper application function during the migration process. A cluster that is already overwhelmed with requests will take much longer to migrate to a larger capacity; if your workload warrants a plan change to increase capacity, migrate to a larger plan early. @@ -35,8 +38,12 @@ For example: Migrate from the smallest, default `dachs-standard` plan to the lar ```bash heroku addons:upgrade foundelasticsearch:beagle-ha --app MY_APP +``` + +Response: +```bash Changing foundelasticsearch-defined-nnnnn on MY_APP from foundelasticsearch:dachs-standard to foundelasticsearch:beagle-ha... done, $201/month ``` -Upgrading to a new plan may involve extending the existing cluster with new nodes and migrating data from the old nodes to the new ones. When the migration is finished, the old nodes are shut down and removed from the cluster. For HA clusters, you can continue to search and index documents while this plan change is happening. +Upgrading to a new plan may involve extending the existing cluster with new nodes and migrating data from the old nodes to the new ones. When the migration is finished, the old nodes are shut down and removed from the cluster. For high availability clusters, you can continue to search and index documents while this plan change is happening. diff --git a/deploy-manage/deploy/elastic-cloud/heroku-reference-hardware.md b/deploy-manage/deploy/elastic-cloud/heroku-reference-hardware.md new file mode 100644 index 0000000000..439896cab9 --- /dev/null +++ b/deploy-manage/deploy/elastic-cloud/heroku-reference-hardware.md @@ -0,0 +1,26 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-reference-hardware.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-aws-instance-configuration.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-default-aws-configurations.html +navigation_title: Hardware +applies_to: + deployment: + ess: +--- + +# {{heroku}} hardware [ech-reference-hardware] + +{{ech}} deployments use a range of virtualized hardware resources from a cloud provider, such as Amazon EC2 (AWS). Instance configurations enable the products and features of the {{stack}} to run on suitable resources that support their intended purpose. For example, if you have a logging use case that benefits from large amounts of slower but more cost-efficient storage space, you can use large spindle drives rather than more expensive SSD storage. Each instance configuration provides a combination of CPU resources, memory, and storage, all of which you can scale from small to very large. + +::::{note} +All instances are set to UTC timezone. +:::: + +The {{heroku}} runs exclusively on AWS. To understand the available hardware, refer to the following resources: + +* [The {{ech}} hardware overview](cloud://reference/cloud-hosted/hardware.md) +* [AWS hardware](cloud://reference/cloud-hosted/aws.md) +* [AWS default hardware](cloud://reference/cloud-hosted/aws-default.md) + +Some hardware profiles might not be available in your region. To learn about regions used by the {{heroku}}, refer to [](/deploy-manage/deploy/elastic-cloud/heroku-reference-regions.md). \ No newline at end of file diff --git a/deploy-manage/deploy/elastic-cloud/ech-reference-regions.md b/deploy-manage/deploy/elastic-cloud/heroku-reference-regions.md similarity index 60% rename from deploy-manage/deploy/elastic-cloud/ech-reference-regions.md rename to deploy-manage/deploy/elastic-cloud/heroku-reference-regions.md index 3083a1edca..7751743761 100644 --- a/deploy-manage/deploy/elastic-cloud/ech-reference-regions.md +++ b/deploy-manage/deploy/elastic-cloud/heroku-reference-regions.md @@ -1,23 +1,25 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-heroku/current/ech-reference-regions.html +navigation_title: Regions +applies_to: + deployment: + ess: --- -# Elasticsearch Add-On for Heroku regions [ech-reference-regions] +# {{heroku}} regions [ech-reference-regions] -A region is the geographic area where the data center of the cloud provider that hosts your deployment is located. Use the information listed here to decide which Elasticsearch Add-On for Heroku region to use. Your choice should be based on: +A region is the geographic area where the data center of the cloud provider that hosts your deployment is located. Use the information listed here to decide which {{heroku}} region to use. Your choice should be based on: * Your geographic proximity to the region. Picking a region that is closer to you typically reduces latency for indexing and search requests. * The features that we support for the region. Not all regions support the same set of features. -Elasticsearch Add-On for Heroku handles all hosting details for you, no additional accounts with the underlying cloud provider required. The region you select cannot be changed after you create a deployment. If you want to use a different region later on, you can create a new deployment and reindex your data into it. +{{heroku}} handles all hosting details for you, no additional accounts with the underlying cloud provider required. The region you select cannot be changed after you create a deployment. If you want to use a different region later on, you can create a new deployment and reindex your data into it. ::::{tip} -If you are not sure what to pick, choose a region that is geographically close to you to reduce latency. You should always use HTTPS to connect to the Elastic stack components of your deployment. +If you are not sure what to pick, choose a region that is geographically close to you to reduce latency. You should always use HTTPS to connect to the {{stack}} components of your deployment. :::: - - ## Amazon Web Services (AWS) regions [echamazon_web_services_aws_regions] The following AWS regions are available: diff --git a/deploy-manage/deploy/elastic-cloud/heroku-working-with-elasticsearch.md b/deploy-manage/deploy/elastic-cloud/heroku-working-with-elasticsearch.md new file mode 100644 index 0000000000..8605e0ade2 --- /dev/null +++ b/deploy-manage/deploy/elastic-cloud/heroku-working-with-elasticsearch.md @@ -0,0 +1,48 @@ +--- +mapped_pages: + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-working-with-elasticsearch.html +applies_to: + deployment: + ess: +--- + +# Work with {{es}} [ech-working-with-elasticsearch] + +You can interact with {{es}} from the command line, or programmatically by sending requests to your {{es}} endpoint. + +::::{tip} +If you are looking for a user interface for {{es}} and your data, go to {{kib}}(/deploy-manage/deploy/elastic-cloud/access-kibana.md). +:::: + +## Find your {{es}} endpoint [echbefore_you_begin_2] + +To find out what the ELASTICSEARCH_URL is for your {{es}} cluster, grep on the output of the `heroku config` command for your app: + +```bash +heroku config --app MY_APP | grep ELASTICSEARCH_URL +ELASTICSEARCH_URL: https://74f176887fdef36bb51e6e37nnnnnnnn.us-east-1.aws.found.io +``` + +When you know your {{es}} URL, you can interact with the {{es}} endpoint using tools like curl. + +## Example [echindexing] + +To index a document into {{es}}, `POST` your document: + +```bash +curl -u USER:PASSWORD https://ELASTICSEARCH_URL/my_index/_doc -XPOST -H 'Content-Type: application/json' -d '{ + "title": "One", "tags": ["ruby"] +}' +``` + +To show that the operation worked, {{es}} returns a JSON response that looks like `{"_index":"my_index","_type":"_doc","_id":"0KNPhW4BnhCSymaq_3SI","_version":1,"result":"created","_shards":{"total":2,"successful":2,"failed":0},"_seq_no":0,"_primary_term":1}`. + +In this example, the index `my_index` is created dynamically when the first document is inserted into it. All documents in {{es}} have a `type` and an `id`, which is echoed as `"_type":"_doc"` and `_id":"0KNPhW4BnhCSymaq_3SI` in the JSON response. If no ID is specified during indexing, a random `id` is generated. + +:::{tip} +These examples use the `elastic` user. If you didn’t copy down the password for the `elastic` user, you can [reset the password](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-elastic-user-cloud.md). +::: + +For more examples, refer to the [document APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-document). You can also use [clients](/reference/elasticsearch/clients/index.md) to interact with these APIs. + +To learn more about working with data in {{es}}, refer to [](/manage-data/index.md). \ No newline at end of file diff --git a/deploy-manage/deploy/elastic-cloud/heroku.md b/deploy-manage/deploy/elastic-cloud/heroku.md index 228d0dc7fd..fe3c0ad378 100644 --- a/deploy-manage/deploy/elastic-cloud/heroku.md +++ b/deploy-manage/deploy/elastic-cloud/heroku.md @@ -2,25 +2,87 @@ mapped_urls: - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started.html - https://www.elastic.co/guide/en/cloud-heroku/current/ech-about.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-getting-started-next-steps.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-restrictions.html +applies_to: + deployment: + ess: +navigation_title: Heroku --- -# Elasticsearch Add-On for Heroku [ech-getting-started] +# {{es}} Add-On for Heroku [ech-getting-started] -% What needs to be done: Refine +This documentation applies to Heroku users who want to make use of the {{es}} Add-On for Heroku that is available from the [Heroku Dashboard](https://dashboard.heroku.com/), or that can be installed from the CLI. -% GitHub issue: https://github.com/elastic/docs-projects/issues/336 +The add-on runs on {{ecloud}} and provides access to [Elasticsearch](https://www.elastic.co/products/elasticsearch), the open source, distributed, RESTful search engine. Many other features of the Elastic Stack are also readily available to Heroku users through the [{{es}} Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) after you install the add-on. For example, you can use {{kib}} to visualize your {{es}} data. -% Scope notes: Refactor this documentation to make it as minimal as possible, working with marketplaces team +To learn more about what plans are available for Heroku users and their cost, refer to the [{{es}} add-on](https://elements.heroku.com/addons/foundelasticsearch) in the Elements Marketplace. -% Use migrated content from existing pages that map to this page: +:::{warning} +The {{es}} Add-on for Heroku has several limitations that do not apply to [other {{ecloud}} sign-up methods](/deploy-manage/deploy/elastic-cloud/create-an-organization.md). To get access to all {{ecloud}} functionality, consider signing up using another method. +::: -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-getting-started.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-about.md +## Limitations -This documentation applies to Heroku users who want to make use of the Elasticsearch Add-On for Heroku that is available from the [Heroku Dashboard](https://dashboard.heroku.com/) or that can be installed from the CLI. +Not all features of {{ecloud}} are available to Heroku users. Specifically, you cannot create additional deployments or use different deployment templates. -The add-on runs on {{ecloud}} and provides access to [Elasticsearch](https://www.elastic.co/products/elasticsearch), the open source, distributed, RESTful search engine. Many other features of the Elastic Stack are also readily available to Heroku users through the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) after you install the add-on. For example, you can use Kibana to visualize your Elasticsearch data. +Generally, if a feature is shown as available in the [{{heroku}} console](https://cloud.elastic.co?page=docs&placement=docs-body), you can use it. -[Elasticsearch Machine Learning](https://www.elastic.co/guide/en/machine-learning/current/index.html), [Elastic APM](/solutions/observability/apps/application-performance-monitoring-apm.md) and [Elastic Fleet Server](https://www.elastic.co/guide/en/fleet/current/fleet-overview.html) are not supported by the Elasticsearch Add-On for Heroku. +[{{es}} Machine Learning](https://www.elastic.co/guide/en/machine-learning/current/index.html), [Elastic APM](/solutions/observability/apps/application-performance-monitoring-apm.md) and [Elastic Fleet Server](https://www.elastic.co/guide/en/fleet/current/fleet-overview.html) are not supported by the {{es}} Add-On for Heroku. -To learn more about what plans are available for Heroku users and their cost, check the [Elasticsearch add-on](https://elements.heroku.com/addons/foundelasticsearch) in the Elements Marketplace. \ No newline at end of file +For other restrictions that apply to all of {{ecloud}}, refer to [](/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md). + +## Get started + +To get started with the {{es}} Add-on for Heroku, [install the add-on](/deploy-manage/deploy/elastic-cloud/heroku-getting-started-installing.md). + +After you install, you can access your deployment: + +* [](/deploy-manage/deploy/elastic-cloud/heroku-getting-started-accessing.md): Access the {{ecloud}} Console for your {{es}} Add-On for Heroku deployment. +* [](/deploy-manage/deploy/elastic-cloud/heroku-working-with-elasticsearch.md): Retrieve the {{es}} endpoint address and send requests to {{es}}. +* [](/deploy-manage/deploy/elastic-cloud/access-kibana.md): Access {{kib}}. +* [Access the API console](cloud://reference/cloud-hosted/ec-api-console.md): Access the API console to make requests without logging into your deployment. + +## Heroku-specific hardware and regions + +The {{es}} Add-on for Heroku in on specific AWS regions only. To learn about the supported AWS regions and hardware, refer to the following pages: + +* [](/deploy-manage/deploy/elastic-cloud/heroku-reference-hardware.md) +* [](/deploy-manage/deploy/elastic-cloud/heroku-reference-regions.md) + +## More about {{ech}} [ec-about] + +Find more information about {{ech}} on the following pages. This information is subject to the {{es}} Add-on for Heroku [limitations](/deploy-manage/deploy/elastic-cloud/heroku.md). + +* [Learn the basics of operating an {{ech}} deployment](/deploy-manage/deploy/elastic-cloud/cloud-hosted.md) +* [](/deploy-manage/deploy/elastic-cloud/manage-deployments.md) +* [](/deploy-manage/license.md) +* [](/deploy-manage/deploy/elastic-cloud/available-stack-versions.md) +* [](/deploy-manage/cloud-organization/service-status.md) +* [Get help](/troubleshoot/index.md) + +## Next steps [next-steps] + +After have provisioned your first deployment, you’re ready to index data into the deployment and explore the advanced capabilities of {{heroku}}. + +### Index data [ech-ingest-data] + +There are several ways to ingest data into the deployment: + +* Use the sample data available from the {{kib}} home page without loading your own data. There are multiple data sets available and you can add them with one click. +* Ingest your own data. [Learn more](/manage-data/ingest.md). +* Have existing {{es}} data? Consider your [migration options](../../../manage-data/migrate.md). + + +### Increase security [ech-increase-security] + +You might want to add more layers of security to your deployment, such as: + +* Add more users to the deployment with third-party authentication providers and services like [SAML](../../users-roles/cluster-or-deployment-auth/saml.md), [OpenID Connect](../../users-roles/cluster-or-deployment-auth/openid-connect.md), or [Kerberos](../../users-roles/cluster-or-deployment-auth/kerberos.md). +* Do not use clients that only support HTTP to connect to Elastic Cloud. If you need to do so, you should use a reverse proxy setup. +* Create [traffic filters](../../security/traffic-filtering.md) and apply them to your deployments. +* If needed, you can [reset](../../users-roles/cluster-or-deployment-auth/built-in-users.md) the `elastic` password. + +### Scale or adjust your deployment [echscale_or_adjust_your_deployment] + +You might find that you need a larger deployment for the workload, or [upgrade the {{es}} version](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-ech.md) for the latest features. All of this can be done after provisioning by [changing your deployment configuration](/deploy-manage/deploy/elastic-cloud/manage-deployments.md). \ No newline at end of file diff --git a/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md b/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md index ede6749bf3..a8492b4c0b 100644 --- a/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md +++ b/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md @@ -13,7 +13,6 @@ mapped_urls: % Use migrated content from existing pages that map to this page: % - [ ] ./raw-migrated-files/cloud/cloud/ec-planning.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-planning.md % Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): @@ -27,5 +26,4 @@ $$$ech-workloads$$$ **This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: -* [/raw-migrated-files/cloud/cloud/ec-planning.md](/raw-migrated-files/cloud/cloud/ec-planning.md) -* [/raw-migrated-files/cloud/cloud-heroku/ech-planning.md](/raw-migrated-files/cloud/cloud-heroku/ech-planning.md) \ No newline at end of file +* [/raw-migrated-files/cloud/cloud/ec-planning.md](/raw-migrated-files/cloud/cloud/ec-planning.md) \ No newline at end of file diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 065de2aed6..94af289c0a 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -18,40 +18,14 @@ toc: - file: deploy/elastic-cloud/google-cloud-platform-marketplace.md - file: deploy/elastic-cloud/heroku.md children: - - file: deploy/elastic-cloud/ech-getting-started-installing.md + - file: deploy/elastic-cloud/heroku-getting-started-installing.md children: - - file: deploy/elastic-cloud/ech-getting-started-installing-version.md - - file: deploy/elastic-cloud/ech-getting-started-removing.md - - file: deploy/elastic-cloud/ech-migrating.md - - file: deploy/elastic-cloud/ech-getting-started-accessing.md - children: - - file: deploy/elastic-cloud/ech-access-kibana.md - - file: deploy/elastic-cloud/ech-working-with-elasticsearch.md - - file: deploy/elastic-cloud/ech-api-console.md - - file: deploy/elastic-cloud/ech-getting-started-next-steps.md - - file: deploy/elastic-cloud/ech-migrate-data2.md - children: - - file: deploy/elastic-cloud/ech-migrate-data-internal.md - - file: deploy/elastic-cloud/ech-about.md - children: - - file: deploy/elastic-cloud/ech-licensing.md - - file: deploy/elastic-cloud/ech-version-policy.md - - file: deploy/elastic-cloud/ech-reference-hardware.md - children: - - file: deploy/elastic-cloud/ech-gcp-instance-configuration.md - - file: deploy/elastic-cloud/ech-default-gcp-configurations.md - - file: deploy/elastic-cloud/ech-aws-instance-configuration.md - - file: deploy/elastic-cloud/ech-default-aws-configurations.md - - file: deploy/elastic-cloud/ech-azure-instance-configuration.md - - file: deploy/elastic-cloud/ech-default-azure-configurations.md - - file: deploy/elastic-cloud/ech-reference-regions.md - - file: deploy/elastic-cloud/ech-service-status.md - children: - - file: deploy/elastic-cloud/echsubscribe_to_individual_regionscomponents.md - - file: deploy/elastic-cloud/echservice_status_api.md - - file: deploy/elastic-cloud/ech-get-help.md - - file: deploy/elastic-cloud/ech-restrictions.md - - file: deploy/elastic-cloud/ech-whats-new.md + - file: deploy/elastic-cloud/heroku-getting-started-removing.md + - file: deploy/elastic-cloud/heroku-getting-started-accessing.md + - file: deploy/elastic-cloud/heroku-working-with-elasticsearch.md + - file: deploy/elastic-cloud/heroku-migrating.md + - file: deploy/elastic-cloud/heroku-reference-hardware.md + - file: deploy/elastic-cloud/heroku-reference-regions.md - file: deploy/elastic-cloud/serverless.md children: - file: deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md b/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md index 4cf60d59da..98368ddae3 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md @@ -11,11 +11,12 @@ navigation_title: "Built-in users" The {{stack-security-features}} provide built-in user credentials to help you get up and running. These users have a fixed set of privileges and cannot be authenticated until their passwords have been set. The `elastic` user can be used to [set all of the built-in user passwords](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md#set-built-in-user-passwords). +In orchestrated deployments (ECH, ECE, and ECK), the `elastic` user is managed by the platform, while other default users are not accessible to end users. To learn how to reset the `elastic` user in an {{ech}}, {{ece}}, or {{eck}} environment, refer to [](/deploy-manage/users-roles/cluster-or-deployment-auth/orchestrator-managed-users-overview.md). + ::::{admonition} Create users with minimum privileges The built-in users serve specific purposes and are not intended for general use. In particular, do not use the `elastic` superuser unless full access to the cluster is absolutely required. On self-managed deployments, use the `elastic` user to create users that have the minimum necessary roles or privileges for their activities. :::: - ::::{note} On {{ecloud}}, [operator privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md) are enabled. These privileges restrict some infrastructure functionality, even if a role would otherwise permit a user to complete an administrative task. :::: diff --git a/docset.yml b/docset.yml index 8eec95c328..568d15bd57 100644 --- a/docset.yml +++ b/docset.yml @@ -277,4 +277,5 @@ subs: eck_version: "3.0.0" apm_server_version: "9.0.0" version: "9.0.0" - release-date: "2-April-2025" \ No newline at end of file + release-date: "2-April-2025" + heroku: "Elasticsearch Add-on for Heroku" \ No newline at end of file diff --git a/manage-data/migrate.md b/manage-data/migrate.md index 0fce52d7a6..b8d4f2ac2a 100644 --- a/manage-data/migrate.md +++ b/manage-data/migrate.md @@ -14,7 +14,7 @@ applies_to: # Migrate your {{es}} data -You might have switched to {{ech}}, {{ece}}, or Elasticsearch Add-On for Heroku for any number of reasons, and you’re likely wondering how to get your existing {{es}} data into your new infrastructure. Along with easily creating as many new deployments with {{es}} clusters that you need, you have several options for moving your data over. Choose the option that works best for you: +You might have switched to {{ech}} or {{ece}} for any number of reasons, and you’re likely wondering how to get your existing {{es}} data into your new infrastructure. Along with easily creating as many new deployments with {{es}} clusters that you need, you have several options for moving your data over. Choose the option that works best for you: * Index your data from the original source, which is the simplest method and provides the greatest flexibility for the {{es}} version and ingestion method. * Reindex from a remote cluster, which rebuilds the index from scratch. @@ -36,7 +36,7 @@ Restore from a snapshot : The new cluster must be the same size as your old one, or larger, to accommodate the data. The new cluster must also be an Elasticsearch version that is compatible with the old cluster (check [Elasticsearch snapshot version compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-restore-version-compatibility) for details). If you have not already done so, you will need to [set up snapshots for your old cluster](/deploy-manage/tools/snapshot-and-restore/self-managed.md) using a repository that can be accessed from the new cluster. Migrating internal {{es}} indices -: For {{ech}} and Elasticsearch Add-On for Heroku, if you are migrating internal {{es}} indices from another cluster, specifically the `.kibana` index or the `.security` index, there are two options: +: For {{ech}}, if you are migrating internal {{es}} indices from another cluster, specifically the `.kibana` index or the `.security` index, there are two options: * Use the steps on this page to reindex the internal indices from a remote cluster. The steps for reindexing internal indices and regular, data indices are the same. * Check [Migrating internal indices](migrate/migrate-internal-indices.md) to restore the internal {{es}} indices from a snapshot. @@ -55,7 +55,7 @@ If the original source isn’t available or has other issues that make it non-vi Through the {{es}} reindex API, you can connect your new {{es}} Service deployment remotely to your old {{es}} cluster. This pulls the data from your old cluster and indexes it into your new one. Reindexing essentially rebuilds the index from scratch and it can be more resource intensive to run. -1. Log in to {{ech}}, {{ece}}, or Elasticsearch Add-On for Heroku. +1. Log in to {{ech}} or {{ece}}. 2. Select a deployment or create one. 3. If the old {{es}} cluster is on a remote host (any type of host accessible over the internet), you need to make sure that the host can be accessed. Access is determined by the {{es}} `reindex.remote.whitelist` user setting. @@ -147,7 +147,7 @@ For {{ece}} users, while it is most common to have Amazon S3 buckets, you should ::::{tab-set} - :::{tab-item} {{ech}} and Elasticsearch Add-On for Heroku + :::{tab-item} {{ech}} From the [console](https://cloud.elastic.co?page=docs&placement=docs-body) of the **new** {{es}} cluster, add the snapshot repository. diff --git a/manage-data/migrate/migrate-internal-indices.md b/manage-data/migrate/migrate-internal-indices.md index 3d9855e7d2..f6018a724c 100644 --- a/manage-data/migrate/migrate-internal-indices.md +++ b/manage-data/migrate/migrate-internal-indices.md @@ -51,28 +51,12 @@ To restore internal indices from a snapshot, the procedure is a bit different fr 3. To restore internal {{es}} indices, you need to register the snapshot repository in `read-only` mode. - ::::{tab-set} - - :::{tab-item} {{ech}} First, add the authentication information for the repository to the {{ech}} keystore, following the steps for your cloud provider: * [AWS S3](../../deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md#ec-snapshot-secrets-keystore) * [Google Cloud Storage](../../deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md#ec-configure-gcs-keystore) * [Azure Blog storage](../../deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md#ec-configure-azure-keystore) Next, register a read-only repository. Open an {{es}} [API console](../../explore-analyze/query-filter/tools/console.md) and run the [Read-only URL repository](../../deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md) API call. - ::: - - :::{tab-item} Elasticsearch Add-On for Heroku - First, add the authentication information for the repository to the Elasticsearch Add-On for Heroku keystore, following the steps for your cloud provider: - * [AWS S3](../../deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md) - * [Google Cloud Storage](../../deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md) - * [Azure Blog storage](../../deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md) - - Next, register a read-only repository. Open an {{es}} [API console](../../explore-analyze/query-filter/tools/console.md) and run the [Read-only URL repository](../../deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md) API call. - - ::: - - :::: 4. Once the repository has been registered and verified, you are ready to restore the internal indices to your new cluster, either all at once or individually. diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-about.md b/raw-migrated-files/cloud/cloud-heroku/ech-about.md deleted file mode 100644 index dbf6f02731..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-about.md +++ /dev/null @@ -1,12 +0,0 @@ -# About [ech-about] - -The information in this section covers: - -* [Subscription Levels](../../../deploy-manage/deploy/elastic-cloud/ech-licensing.md) -* [Version Policy](../../../deploy-manage/deploy/elastic-cloud/ech-version-policy.md) -* [Elasticsearch Add-On for Heroku Hardware](../../../deploy-manage/deploy/elastic-cloud/ech-reference-hardware.md) -* [Elasticsearch Add-On for Heroku Regions](../../../deploy-manage/deploy/elastic-cloud/ech-reference-regions.md) -* [Service Status](../../../deploy-manage/deploy/elastic-cloud/ech-service-status.md) -* [Getting help](../../../deploy-manage/deploy/elastic-cloud/ech-get-help.md) -* [Restrictions and known problems](../../../deploy-manage/deploy/elastic-cloud/ech-restrictions.md) - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-access-kibana.md b/raw-migrated-files/cloud/cloud-heroku/ech-access-kibana.md deleted file mode 100644 index 645a1e5384..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-access-kibana.md +++ /dev/null @@ -1,33 +0,0 @@ -# Access Kibana [ech-access-kibana] - -Kibana is an open source analytics and visualization platform designed to search, view, and interact with data stored in Elasticsearch indices. The use of Kibana is included with your subscription. - -For new Elasticsearch clusters, we automatically create a Kibana instance for you. - -To access Kibana: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. Under **Applications**, select the Kibana **Launch** link and wait for Kibana to open. - - ::::{note} - Both ports 443 and 9243 can be used to access Kibana. SSO only works with 9243 on older deployments, where you will see an option in the Cloud UI to migrate the default to port 443. In addition, any version upgrade will automatically migrate the default port to 443. - :::: - -4. Log into Kibana. Single sign-on (SSO) is enabled between your Cloud account and the Kibana instance. If you’re logged in already, then Kibana opens without requiring you to log in again. However, if your token has expired, choose from one of these methods to log in: - - * Select **Login with Cloud**. You’ll need to log in with your Cloud account credentials and then you’ll be redirected to Kibana. - * Log in with the `elastic` superuser. The password was provided when you created your cluster or [can be reset](../../../deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). - * Log in with any users you created in Kibana already. - - -In production systems, you might need to control what Elasticsearch data users can access through Kibana, so you need create credentials that can be used to access the necessary Elasticsearch resources. This means granting read access to the necessary indexes, as well as access to update the `.kibana` index. - -::::{tip} -If your cluster didn’t include a Kibana instance initially, there might not be a Kibana endpoint URL shown, yet. To gain access, all you need to do is [enable Kibana first](../../../deploy-manage/deploy/elastic-cloud/access-kibana.md). -:::: - - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-activity-page.md b/raw-migrated-files/cloud/cloud-heroku/ech-activity-page.md deleted file mode 100644 index 82f4edf3b1..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-activity-page.md +++ /dev/null @@ -1,37 +0,0 @@ -# Keep track of deployment activity [ech-activity-page] - -The deployment **Activity** page gives you a convenient way to follow all configuration changes that have been applied to your deployment, including which resources were affected, when the changes were applied, who initiated the changes, and whether or not the changes were successful. You can also select **Details** for an expanded, step-by-step view of each change applied to each deployment resource. - -To view the activity for a deployment: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. In your deployment menu, select **Activity**. -4. You can: - - 1. View the activity for all deployment resources (the default). - 2. Use one of the available filters to view configuration changes by status or type. You can use the query field to create a custom search. Select the filter buttons to get examples of the query format. - 3. Select one of the resource filters to view activity for only that resource type. - - -:::{image} ../../../images/cloud-heroku-ec-ce-activity-page.png -:alt: The Activity page -::: - -In the table columns you find the following information: - -Change -: Which deployment resource the configuration change was applied to. - -Summary -: A summary of what change was applied, when the change was performed, and how long it took. - -Applied by -: The user who submitted the configuration change. `System` indicates configuration changes initiated automatically by the Elasticsearch Add-On for Heroku platform. - -Actions -: Select **Details** for an expanded view of each step in the configuration change, including the start time, end time, and duration. You can select **Reapply** to re-run the configuration change. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-add-user-settings.md b/raw-migrated-files/cloud/cloud-heroku/ech-add-user-settings.md deleted file mode 100644 index 861c66aa49..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-add-user-settings.md +++ /dev/null @@ -1,291 +0,0 @@ -# Edit {{es}} user settings [ech-add-user-settings] - -Change how {{es}} runs by providing your own user settings. Elasticsearch Add-On for Heroku appends these settings to each node’s `elasticsearch.yml` configuration file. - -Elasticsearch Add-On for Heroku automatically rejects `elasticsearch.yml` settings that could break your cluster. For a list of supported settings, check [Supported {{es}} settings](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#ech-es-elasticsearch-settings). - -::::{warning} -You can also update [dynamic cluster settings](../../../deploy-manage/deploy/self-managed/configure-elasticsearch.md#dynamic-cluster-setting) using {{es}}'s [update cluster settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). However, Elasticsearch Add-On for Heroku doesn’t reject unsafe setting changes made using this API. Use with caution. -:::: - - -To add or edit user settings: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. From your deployment menu, go to the **Edit** page. -4. In the **Elasticsearch** section, select **Manage user settings and extensions**. -5. Update the user settings. -6. Select **Save changes**. - -::::{note} -In some cases, you may get a warning saying "User settings are different across Elasticsearch instances". To fix this issue, ensure that your user settings (including the comments sections and whitespaces) are identical across all Elasticsearch nodes (not only the data tiers, but also the Master, Machine Learning, and Coordinating nodes). -:::: - - -## Supported {{es}} settings [ech-es-elasticsearch-settings] - -Elasticsearch Add-On for Heroku supports the following `elasticsearch.yml` settings. - -### General settings [echgeneral_settings] - -The following general settings are supported: - -$$$http-cors-settings$$$`http.cors.*` -: Enables cross-origin resource sharing (CORS) settings for the [HTTP module](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md). - - ::::{note} - If your use case depends on the ability to receive CORS requests and you have a cluster that was provisioned prior to January 25th 2019, you must manually set `http.cors.enabled` to `true` and allow a specific set of hosts with `http.cors.allow-origin`. Applying these changes in your Elasticsearch configuration allows cross-origin resource sharing requests. - :::: - - -`http.compression` -: Support for [HTTP compression](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) when possible (with Accept-Encoding). Defaults to `true`. - -`transport.compress` -: Configures [transport compression](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) for node-to-node traffic. - -`transport.compression_scheme` -: Configures [transport compression](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) for node-to-node traffic. - -`repositories.url.allowed_urls` -: Enables explicit allowing of [read-only URL repositories](../../../deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md). - -`reindex.remote.whitelist` -: Explicitly allows the set of hosts that can be [reindexed from remotely](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex). Expects a YAML array of `host:port` strings. Consists of a comma-delimited list of `host:port` entries. Defaults to `["\*.io:*", "\*.com:*"]`. - -`reindex.ssl.*` -: To learn more on how to configure reindex SSL user settings, check [configuring reindex SSL parameters](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex). - -`script.painless.regex.enabled` -: Enables [regular expressions](elasticsearch://reference/scripting-languages/painless/brief-painless-walkthrough.md#modules-scripting-painless-regex) for the Painless scripting language. - -`action.auto_create_index` -: [Automatically create index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-create) if it doesn’t already exist. - -`action.destructive_requires_name` -: When set to `true`, users must [specify the index name](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-delete) to delete an index. It’s not possible to delete _all or use wildcards. - -`xpack.notification.webhook.additional_token_enabled` -: When set to `true`, {{es}} automatically sets a token which enables the bypassing of traffic filters for calls initiated by Watcher towards {{es}} or {{kib}}. The default is `false` and the feature is available starting with {{es}} version 8.7.1 and later. - - ::::{important} - This setting only applies to the Watcher `webhook` action, not the `http` input action. - :::: - - -`cluster.indices.close.enable` -: Enables closing indices in Elasticsearch. Defaults to `true` for versions 7.2.0 and later, and to `false` for previous versions. In versions 7.1 and below, closed indices represent a data loss risk: if you close an index, it is not included in snapshots and you will not be able to restore the data. Similarly, closed indices are not included when you make cluster configuration changes, such as scaling to a different capacity, failover, and many other operations. Lastly, closed indices can lead to inaccurate disk space counts. - - ::::{warning} - For versions 7.1 and below, closed indices represent a data loss risk. Enable this setting only temporarily for these versions. - :::: - - -`azure.client.CLIENT_NAME.endpoint_suffix` -: Allows providing the [endpoint_suffix client setting](../../../deploy-manage/tools/snapshot-and-restore/azure-repository.md#repository-azure-client-settings) for a non-internal Azure client used for snapshot/restore. Note that `CLIENT_NAME` should be replaced with the name of the created client. - - -### Circuit breaker settings [echcircuit_breaker_settings] - -The following circuit breaker settings are supported: - -`indices.breaker.total.limit` -: Configures [the parent circuit breaker settings](elasticsearch://reference/elasticsearch/configuration-reference/circuit-breaker-settings.md#parent-circuit-breaker). - -`indices.breaker.fielddata.limit` -: Configures [the limit for the fielddata breaker](elasticsearch://reference/elasticsearch/configuration-reference/circuit-breaker-settings.md#fielddata-circuit-breaker). - -`indices.breaker.fielddata.overhead` -: Configures [a constant that all field data estimations are multiplied with to determine a final estimation](elasticsearch://reference/elasticsearch/configuration-reference/circuit-breaker-settings.md#fielddata-circuit-breaker). - -`indices.breaker.request.limit` -: Configures [the limit for the request breaker](elasticsearch://reference/elasticsearch/configuration-reference/circuit-breaker-settings.md#request-circuit-breaker). - -`indices.breaker.request.overhead` -: Configures [a constant that all request estimations are multiplied by to determine a final estimation](elasticsearch://reference/elasticsearch/configuration-reference/circuit-breaker-settings.md#request-circuit-breaker). - - -### Indexing pressure settings [echindexing_pressure_settings] - -The following indexing pressure settings are supported: - -`indexing_pressure.memory.limit` -: Configures [the indexing pressure settings](elasticsearch://reference/elasticsearch/index-settings/pressure.md). - - -### X-Pack [echx_pack] - -#### Version 8.5.3+, 7.x support in 7.17.8+ [echversion_8_5_3_7_x_support_in_7_17_8] - -`xpack.security.transport.ssl.trust_restrictions.x509_fields` -: Specifies which field(s) from the TLS certificate is used to match for the restricted trust management that is used for remote clusters connections. This should only be set when a self managed cluster can not create certificates that follow the Elastic Cloud pattern. The default value is ["subjectAltName.otherName.commonName"], the Elastic Cloud pattern. "subjectAltName.dnsName" is also supported and can be configured in addition to or in replacement of the default. - - -#### All supported versions [echall_supported_versions] - -`xpack.ml.inference_model.time_to_live` -: Sets the duration of time that the trained models are cached. Check [{{ml-cap}} settings](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md). - -`xpack.security.loginAssistanceMessage` -: Adds a message to the login screen. Useful for displaying corporate messages. - -`xpack.security.authc.anonymous.*` -: To learn more on how to enable anonymous access, check [Enabling anonymous access](/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md) - -`xpack.notification.slack` -: Configures [Slack notification settings](/explore-analyze/alerts-cases/watcher/actions-slack.md). Note that you need to add `secure_url` as a [secret value to the keystore](../../../deploy-manage/security/secure-settings.md). - -`xpack.notification.pagerduty` -: Configures [PagerDuty notification settings](/explore-analyze/alerts-cases/watcher/actions-pagerduty.md#configuring-pagerduty). - -`xpack.watcher.trigger.schedule.engine` -: Defines when the watch should start, based on date and time [Learn more](/explore-analyze/alerts-cases/watcher/trigger-schedule.md). - -`xpack.notification.email.html.sanitization.*` -: Enables [email notification settings](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md) to sanitize HTML elements in emails that are sent. - -`xpack.monitoring.collection.interval` -: Controls [how often data samples are collected](elasticsearch://reference/elasticsearch/configuration-reference/monitoring-settings.md#monitoring-collection-settings). - -`xpack.monitoring.collection.min_interval_seconds` -: Specifies the minimum number of seconds that a time bucket in a chart can represent. If you modify the `xpack.monitoring.collection.interval`, use the same value in this setting. - - Defaults to `10` (10 seconds). - - -$$$xpack-monitoring-history-duration$$$`xpack.monitoring.history.duration` -: Sets the [retention duration](elasticsearch://reference/elasticsearch/configuration-reference/monitoring-settings.md#monitoring-collection-settings) beyond which the indices created by a monitoring exporter will be automatically deleted. - -`xpack.watcher.history.cleaner_service.enabled` -: Controls [whether old watcher indices are automatically deleted](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md#general-notification-settings). - -`xpack.http.ssl.cipher_suites` -: Controls the list of supported cipher suites for all outgoing TLS connections. - -`xpack.security.authc.realms.saml.*` -: To learn more on how to enable SAML and related user settings, check [secure your clusters with SAML](../../../deploy-manage/users-roles/cluster-or-deployment-auth/saml.md). - -`xpack.security.authc.realms.oidc.*` -: To learn more on how to enable OpenID Connect and related user settings, check [secure your clusters with OpenID Connect](../../../deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md). - -`xpack.security.authc.realms.kerberos.*` -: To learn more on how to enable Kerberos and relate user settings, check [secure your clusters with Kerberos](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md). - -`xpack.security.authc.realms.jwt.*` -: To learn more on how to enable JWT and related user settings, check [secure your clusters with JWT](../../../deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md). - -::::{note} -All SAML, OpenID Connect, Kerberos, and JWT settings are allowlisted. -:::: - - - - -### Search [echsearch] - -The following search settings are supported: - -* `search.aggs.rewrite_to_filter_by_filter` - - -### Disk-based shard allocation settings [shard-allocation-settings] - -The following disk-based allocation settings are supported: - -`cluster.routing.allocation.disk.threshold_enabled` -: Enable or disable [disk allocation](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#disk-based-shard-allocation) decider and defaults to `true`. - -`cluster.routing.allocation.disk.watermark.low` -: Configures [disk-based shard allocation’s low watermark](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#disk-based-shard-allocation). - -`cluster.routing.allocation.disk.watermark.high` -: Configures [disk-based shard allocation’s high watermark](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#disk-based-shard-allocation). - -`cluster.routing.allocation.disk.watermark.flood_stage` -: Configures [disk-based shard allocation’s flood_stage](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#disk-based-shard-allocation). - -::::{tip} -Remember to update user settings for alerts when performing a major version upgrade. -:::: - - - -### Enrich settings [echenrich_settings] - -The following enrich settings are supported: - -`enrich.cache_size` -: Maximum number of searches to cache for enriching documents. Defaults to 1000. There is a single cache for all enrich processors in the cluster. This setting determines the size of that cache. - -`enrich.coordinator_proxy.max_concurrent_requests` -: Maximum number of concurrent multi-search requests to run when enriching documents. Defaults to 8. - -`enrich.coordinator_proxy.max_lookups_per_request` -: Maximum number of searches to include in a multi-search request when enriching documents. Defaults to 128. - -`enrich.coordinator_proxy.queue_capacity` -: coordinator queue capacity, defaults to max_concurrent_requests * max_lookups_per_request - - -### Audit settings [echaudit_settings] - -The following audit settings are supported: - -`xpack.security.audit.enabled` -: Enables auditing on Elasticsearch cluster nodes. Defaults to *false*. - -`xpack.security.audit.logfile.events.include` -: Specifies which events to include in the auditing output. - -`xpack.security.audit.logfile.events.exclude` -: Specifies which events to exclude from the output. No events are excluded by default. - -`xpack.security.audit.logfile.events.emit_request_body` -: Specifies whether to include the request body from REST requests on certain event types, for example *authentication_failed*. Defaults to *false*. - -`xpack.security.audit.logfile.emit_node_name` -: Specifies whether to include the node name as a field in each audit event. Defaults to *true*. - -`xpack.security.audit.logfile.emit_node_host_address` -: Specifies whether to include the node’s IP address as a field in each audit event. Defaults to *false*. - -`xpack.security.audit.logfile.emit_node_host_name` -: Specifies whether to include the node’s host name as a field in each audit event. Defaults to *false*. - -`xpack.security.audit.logfile.emit_node_id` -: Specifies whether to include the node ID as a field in each audit event. Defaults to *true*. - -`xpack.security.audit.logfile.events.ignore_filters..users` -: A list of user names or wildcards. The specified policy will not print audit events for users matching these values. - -`xpack.security.audit.logfile.events.ignore_filters..realms` -: A list of authentication realm names or wildcards. The specified policy will not print audit events for users in these realms. - -`xpack.security.audit.logfile.events.ignore_filters..roles` -: A list of role names or wildcards. The specified policy will not print audit events for users that have these roles. - -`xpack.security.audit.logfile.events.ignore_filters..indices` -: A list of index names or wildcards. The specified policy will not print audit events when all the indices in the event match these values. - -`xpack.security.audit.logfile.events.ignore_filters..actions` -: A list of action names or wildcards. The specified policy will not print audit events for actions matching these values. - -::::{note} -To enable auditing you must first [enable deployment logging](../../../deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md). -:::: - - - -### Universal Profiling settings [echuniversal_profiling_settings] - -The following settings for Elastic Universal Profiling are supported: - -`xpack.profiling.enabled` -: *Version 8.7.0+*: Specifies whether the Universal Profiling Elasticsearch plugin is enabled. Defaults to *true*. - -`xpack.profiling.templates.enabled` -: *Version 8.9.0+*: Specifies whether Universal Profiling related index templates should be created on startup. Defaults to *false*. diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-custom-repository.md b/raw-migrated-files/cloud/cloud-heroku/ech-custom-repository.md deleted file mode 100644 index 5e0af9b395..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-custom-repository.md +++ /dev/null @@ -1,23 +0,0 @@ -# Snapshot and restore with custom repositories - -Specify your own repositories to snapshot to and restore from. This can be useful, for example, to do long-term archiving of old indexes, restore snapshots across Elastic Cloud accounts, or to be certain you have an exit strategy, should you need to move away from our service. - -Elasticsearch Add-On for Heroku supports these repositories: - -* [Amazon Web Services (AWS)](../../../deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md) -* [Google Cloud Storage (GCS)](../../../deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md) -* [Azure Blob Storage](../../../deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md) - -::::{note} -Automated snapshots are only available in the *found snapshots* repository. You are responsible for the execution and maintenance of the snapshots that you store in custom repositories. Note that the automated snapshot frequency might conflict with manual snapshots. You can enable SLM to automate snapshot management in a custom repository. -:::: - - -::::{tip} -By using a custom repository, you can restore snapshots across regions. -:::: - - - - - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-delete-deployment.md b/raw-migrated-files/cloud/cloud-heroku/ech-delete-deployment.md deleted file mode 100644 index 410fa2bb2c..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-delete-deployment.md +++ /dev/null @@ -1,18 +0,0 @@ -# Delete your deployment [ech-delete-deployment] - -To do that, select **Delete deployment** from the deployment overview page. - -When you delete your deployment, billing stops immediately rounding up to the nearest hour. - -::::{warning} -When deployments are deleted, we erase all data on disk, including snapshots. Snapshots are retained for very a limited amount of time post deletion and we cannot guarantee that deleted deployments can be restored from snapshots for this reason. If you accidentally delete a deployment, please contact support as soon as possible to increase the likelihood of restoring your deployment. -:::: - - -::::{tip} -If you want to keep the snapshot for future purposes even after the deployment deletion, you should [use a custom snapshot repository](../../../deploy-manage/tools/snapshot-and-restore/elastic-cloud-hosted.md). -:::: - - -Billing restarts as soon as the deployment is restored. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-editing-user-settings.md b/raw-migrated-files/cloud/cloud-heroku/ech-editing-user-settings.md deleted file mode 100644 index 1e0ea46b76..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-editing-user-settings.md +++ /dev/null @@ -1,11 +0,0 @@ -# Edit your user settings [ech-editing-user-settings] - -From the Elasticsearch Add-On for Heroku console you can customize Elasticsearch, Kibana, and related products to suit your needs. These editors append your changes to the appropriate YAML configuration file and they affect all users of that cluster. In each editor you can: - -* [Dictate the behavior of Elasticsearch and its security features](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md). -* [Manage Kibana’s settings](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md). -* [Tune your APM Server](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md). - - - - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-enable-kibana2.md b/raw-migrated-files/cloud/cloud-heroku/ech-enable-kibana2.md deleted file mode 100644 index c199b85b16..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-enable-kibana2.md +++ /dev/null @@ -1,16 +0,0 @@ -# Enable Kibana [ech-enable-kibana2] - -If your deployment didn’t include a Kibana instance initially, use these instructions to enable Kibana first. For new Elasticsearch clusters, we automatically create a Kibana instance for you that you can access directly. The use of Kibana is included with your subscription. - -To enable Kibana on your deployment: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. From your deployment menu, go to the **Kibana** page. -4. Select **Enable**. - -Enabling Kibana provides you with an endpoint URL, where you can access Kibana. It can take a short while to provision Kibana right after you select **Enable**, so if you get an error message when you first access the endpoint URL, wait a bit and try again. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-getting-started.md b/raw-migrated-files/cloud/cloud-heroku/ech-getting-started.md deleted file mode 100644 index e39dba7a54..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-getting-started.md +++ /dev/null @@ -1,10 +0,0 @@ -# Introducing Elasticsearch Add-On for Heroku [ech-getting-started] - -This documentation applies to Heroku users who want to make use of the Elasticsearch Add-On for Heroku that is available from the [Heroku Dashboard](https://dashboard.heroku.com/) or that can be installed from the CLI. - -The add-on runs on {{ecloud}} and provides access to [Elasticsearch](https://www.elastic.co/products/elasticsearch), the open source, distributed, RESTful search engine. Many other features of the Elastic Stack are also readily available to Heroku users through the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body) after you install the add-on. For example, you can use Kibana to visualize your Elasticsearch data. - -[Elasticsearch Machine Learning](/explore-analyze/machine-learning.md), [Elastic Enterprise Search](https://www.elastic.co/guide/en/enterprise-search/current/index.html), [Elastic APM](/solutions/observability/apps/application-performance-monitoring-apm.md) and [Elastic Fleet Server](/reference/ingestion-tools/fleet/index.md) are not supported by the Elasticsearch Add-On for Heroku. - -To learn more about what plans are available for Heroku users and their cost, check the [Elasticsearch add-on](https://elements.heroku.com/addons/foundelasticsearch) in the Elements Marketplace. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-manage-apm-settings.md b/raw-migrated-files/cloud/cloud-heroku/ech-manage-apm-settings.md deleted file mode 100644 index 0273036530..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-manage-apm-settings.md +++ /dev/null @@ -1,369 +0,0 @@ -# Edit APM user settings [ech-manage-apm-settings] - -Change how Elastic APM runs by providing your own user settings. Starting in {{stack}} version 8.0, how you change APM settings and the settings that are available to you depend on how you spin up Elastic APM. There are two modes: - -{{fleet}}-managed APM integration -: New deployments created in {{stack}} version 8.0 and later will be managed by {{fleet}}. - - Check [APM configuration reference](/solutions/observability/apps/configure-apm-server.md) for information on how to configure Elastic APM in this mode. - - -Standalone APM Server (legacy) -: Deployments created prior to {{stack}} version 8.0 are in legacy mode. Upgrading to or past {{stack}} 8.0 will not remove you from legacy mode. - - Check [Edit standalone APM settings (legacy)](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#ech-edit-apm-standalone-settings) and [Supported standalone APM settings (legacy)](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#ech-apm-settings) for information on how to configure Elastic APM in this mode. - - -To learn more about the differences between these modes, or to switch from Standalone APM Server (legacy) mode to {{fleet}}-managed, check [Switch to the Elastic APM integration](/solutions/observability/apps/switch-to-elastic-apm-integration.md). - -## Edit standalone APM settings (legacy) [ech-edit-apm-standalone-settings] - -User settings are appended to the `apm-server.yml` configuration file for your instance and provide custom configuration options. - -To add user settings: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. From your deployment menu, go to the **Edit** page. -4. In the **APM** section, select **Edit user settings**. (For existing deployments with user settings, you may have to expand the **Edit apm-server.yml** caret instead.) -5. Update the user settings. -6. Select **Save changes**. - -::::{note} -If a setting is not supported by Elasticsearch Add-On for Heroku, you will get an error message when you try to save. -:::: - - - -## Supported standalone APM settings (legacy) [ech-apm-settings] - -Elasticsearch Add-On for Heroku supports the following setting when running APM in standalone mode (legacy). - -::::{tip} -Some settings that could break your cluster if set incorrectly are blocklisted. The following settings are generally safe in cloud environments. For detailed information about APM settings, check the [APM documentation](/solutions/observability/apps/configure-apm-server.md). -:::: - - -### Version 8.0+ [echversion_8_0_3] - -This stack version removes support for some previously supported settings. These are all of the supported settings for this version: - -`apm-server.agent.config.cache.expiration` -: When using APM agent configuration, determines cache expiration from information fetched from Kibana. Defaults to `30s`. - -`apm-server.aggregation.transactions.*` -: This functionality is experimental and may be changed or removed completely in a future release. When enabled, APM Server produces transaction histogram metrics that are used to power the APM app. Shifting this responsibility from APM app to APM Server results in improved query performance and removes the need to store unsampled transactions. - -The following `apm-server.auth.anonymous.*` settings can be configured to restrict anonymous access to specified agents and/or services. This is primarily intended to allow limited access for untrusted agents, such as Real User Monitoring. Anonymous auth is automatically enabled when RUM is enabled. Otherwise, anonymous auth is disabled. When anonymous auth is enabled, only agents matching `allow_agent` and services matching `allow_service` are allowed. See below for details on default values for these. - -`apm-server.auth.anonymous.allow_agent` -: Allow anonymous access only for specified agents. - -`apm-server.auth.anonymous.allow_service` -: Allow anonymous access only for specified service names. By default, all service names are allowed. This is replacing the config option `apm-server.rum.allow_service_names`, previously available for `7.x` deployments. - -`apm-server.auth.anonymous.rate_limit.event_limit` -: Rate limiting is defined per unique client IP address, for a limited number of IP addresses. Sites with many concurrent clients should consider increasing this limit. Defaults to 1000. This is replacing the config option `apm-server.rum.event_rate.limit`, previously available for `7.x` deployments. - -`apm-server.auth.anonymous.rate_limit.ip_limit` -: Defines the maximum amount of events allowed per IP per second. Defaults to 300. The overall maximum event throughput for anonymous access is (event_limit * ip_limit). This is replacing the config option `apm-server.rum.event_rate.lru_size`, previously available for `7.x` deployments. - -`apm-server.auth.api_key.enabled` -: Enables agent authorization using Elasticsearch API Keys. This is replacing the config option `apm-server.api_key.enabled`, previously available for `7.x` deployments. - -`apm-server.auth.api_key.limit` -: Restrict how many unique API keys are allowed per minute. Should be set to at least the amount of different API keys configured in your monitored services. Every unique API key triggers one request to Elasticsearch. This is replacing the config option `apm-server.api_key.limit`, previously available for `7.x` deployments. - -`apm-server.capture_personal_data` -: When set to `true`, the server captures the IP of the instrumented service and its User Agent. Enabled by default. - -`apm-server.default_service_environment` -: If specified, APM Server will record this value in events which have no service environment defined, and add it to agent configuration queries to Kibana when none is specified in the request from the agent. - -`apm-server.max_event_size` -: Specifies the maximum allowed size of an event for processing by the server, in bytes. Defaults to `307200`. - -`apm-server.rum.allow_headers` -: A list of Access-Control-Allow-Headers to allow RUM requests, in addition to "Content-Type", "Content-Encoding", and "Accept". - -`apm-server.rum.allow_origins` -: A list of permitted origins for real user monitoring. User-agents will send an origin header that will be validated against this list. An origin is made of a protocol scheme, host, and port, without the URL path. Allowed origins in this setting can have a wildcard `*` to match anything (for example: `http://*.example.com`). If an item in the list is a single `*`, all origins will be allowed. - -`apm-server.rum.enabled` -: Enable Real User Monitoring (RUM) Support. By default RUM is enabled. RUM does not support token based authorization. Enabled RUM endpoints will not require any authorization configured for other endpoints. - -`apm-server.rum.exclude_from_grouping` -: A regexp to be matched against a stacktrace frame’s `file_name`. If the regexp matches, the stacktrace frame is not used for calculating error groups. The default pattern excludes stacktrace frames that have a filename starting with `/webpack` - -`apm-server.rum.library_pattern` -: A regexp to be matched against a stacktrace frame’s `file_name` and `abs_path` attributes. If the regexp matches, the stacktrace frame is considered to be a library frame. - -`apm-server.rum.source_mapping.enabled` -: If a source map has previously been uploaded, source mapping is automatically applied to all error and transaction documents sent to the RUM endpoint. Sourcemapping is enabled by default when RUM is enabled. - -`apm-server.rum.source_mapping.cache.expiration` -: The `cache.expiration` determines how long a source map should be cached in memory. Note that values configured without a time unit will be interpreted as seconds. - -`apm-server.sampling.tail.enabled` -: Set to `true` to enable tail based sampling. Disabled by default. - -`apm-server.sampling.tail.policies` -: Criteria used to match a root transaction to a sample rate. - -`apm-server.sampling.tail.interval` -: Synchronization interval for multiple APM Servers. Should be in the order of tens of seconds or low minutes. - -`logging.level` -: Sets the minimum log level. The default log level is error. Available log levels are: error, warning, info, or debug. - -`logging.selectors` -: Enable debug output for selected components. To enable all selectors use ["*"]. Other available selectors are "beat", "publish", or "service". Multiple selectors can be chained. - -`logging.metrics.enabled` -: If enabled, apm-server periodically logs its internal metrics that have changed in the last period. For each metric that changed, the delta from the value at the beginning of the period is logged. Also, the total values for all non-zero internal metrics are logged on shutdown. The default is false. - -`logging.metrics.period` -: The period after which to log the internal metrics. The default is 30s. - -`max_procs` -: Sets the maximum number of CPUs that can be executing simultaneously. The default is the number of logical CPUs available in the system. - -`output.elasticsearch.flush_interval` -: The maximum duration to accumulate events for a bulk request before being flushed to Elasticsearch. The value must have a duration suffix. The default is 1s. - -`output.elasticsearch.flush_bytes` -: The bulk request size threshold, in bytes, before flushing to Elasticsearch. The value must have a suffix. The default is 5MB. - - -### Version 7.17+ [echversion_7_17] - -This stack version includes all of the settings from 7.16 and the following: - -Allow anonymous access only for specified agents and/or services. This is primarily intended to allow limited access for untrusted agents, such as Real User Monitoring. Anonymous auth is automatically enabled when RUM is enabled. Otherwise, anonymous auth is disabled. When anonymous auth is enabled, only agents matching allow_agent and services matching allow_service are allowed. See below for details on default values for these. - -`apm-server.auth.anonymous.allow_agent` -: Allow anonymous access only for specified agents. - -`apm-server.auth.anonymous.allow_service` -: Allow anonymous access only for specified service names. By default, all service names are allowed. This will be replacing the config option `apm-server.rum.allow_service_names` from `8.0` on. - -`apm-server.auth.anonymous.rate_limit.event_limit` -: Rate limiting is defined per unique client IP address, for a limited number of IP addresses. Sites with many concurrent clients should consider increasing this limit. Defaults to 1000. This will be replacing the config option`apm-server.rum.event_rate.limit` from `8.0` on. - -`apm-server.auth.anonymous.rate_limit.ip_limit` -: Defines the maximum amount of events allowed per IP per second. Defaults to 300. The overall maximum event throughput for anonymous access is (event_limit * ip_limit). This will be replacing the config option `apm-server.rum.event_rate.lru_size` from `8.0` on. - -`apm-server.auth.api_key.enabled` -: Enables agent authorization using Elasticsearch API Keys. This will be replacing the config option `apm-server.api_key.enabled` from `8.0` on. - -`apm-server.auth.api_key.limit` -: Restrict how many unique API keys are allowed per minute. Should be set to at least the amount of different API keys configured in your monitored services. Every unique API key triggers one request to Elasticsearch. This will be replacing the config option `apm-server.api_key.limit` from `8.0` on. - - -### Supported versions before 8.x [echsupported_versions_before_8_x_3] - -`apm-server.aggregation.transactions.*` -: This functionality is experimental and may be changed or removed completely in a future release. When enabled, APM Server produces transaction histogram metrics that are used to power the APM app. Shifting this responsibility from APM app to APM Server results in improved query performance and removes the need to store unsampled transactions. - -`apm-server.default_service_environment` -: If specified, APM Server will record this value in events which have no service environment defined, and add it to agent configuration queries to Kibana when none is specified in the request from the agent. - -`apm-server.rum.allow_service_names` -: A list of service names to allow, to limit service-specific indices and data streams created for unauthenticated RUM events. If the list is empty, any service name is allowed. - -`apm-server.ilm.setup.mapping` -: ILM policies now support configurable index suffixes. You can append the `policy_name` with an `index_suffix` based on the `event_type`, which can be one of `span`, `transaction`, `error`, or `metric`. - -`apm-server.rum.allow_headers` -: List of Access-Control-Allow-Headers to allow RUM requests, in addition to "Content-Type", "Content-Encoding", and "Accept". - -`setup.template.append_fields` -: A list of fields to be added to the Elasticsearch template and Kibana data view (formerly *index pattern*). - -`apm-server.api_key.enabled` -: Enabled by default. For any requests where APM Server accepts a `secret_token` in the authorization header, it now alternatively accepts an API Key. - -`apm-server.api_key.limit` -: Configure how many unique API keys are allowed per minute. Should be set to at least the amount of different API keys used in monitored services. Default value is 100. - -`apm-server.ilm.setup.enabled` -: When enabled, APM Server creates aliases, event type specific settings and ILM policies. If disabled, event type specific templates need to be managed manually. - -`apm-server.ilm.setup.overwrite` -: Set to `true` to apply custom policies and to properly overwrite templates when switching between using ILM and not using ILM. - -`apm-server.ilm.setup.require_policy` -: Set to `false` when policies are set up outside of APM Server but referenced in this configuration. - -`apm-server.ilm.setup.policies` -: Array of ILM policies. Each entry has a `name` and a `policy`. - -`apm-server.ilm.setup.mapping` -: Array of mappings of ILM policies to event types. Each entry has a `policy_name` and an `event_type`, which can be one of `span`, `transaction`, `error`, or `metric`. - -`apm-server.rum.source_mapping.enabled` -: When events are monitored using the RUM agent, APM Server tries to apply source mapping by default. This configuration option allows you to disable source mapping on stack traces. - -`apm-server.rum.source_mapping.cache.expiration` -: Sets how long a source map should be cached before being refetched from Elasticsearch. Default value is 5m. - -`output.elasticsearch.pipeline` -: APM comes with a default pipeline definition. This allows overriding it. To disable, you can set `pipeline: _none` - -`apm-server.agent.config.cache.expiration` -: When using APM agent configuration, determines cache expiration from information fetched from Kibana. Defaults to `30s`. - -`apm-server.ilm.enabled` -: Enables index lifecycle management (ILM) for the indices created by the APM Server. Defaults to `false`. If you’re updating an existing APM Server, you must also set `setup.template.overwrite: true`. If you don’t, the index template will not be overridden and ILM changes will not take effect. - -`apm-server.max_event_size` -: Specifies the maximum allowed size of an event for processing by the server, in bytes. Defaults to `307200`. - -`output.elasticsearch.pipelines` -: Adds an array for pipeline selector configurations that support conditionals, format string-based field access, and name mappings used to [parse data using ingest node pipelines](/solutions/observability/apps/application-performance-monitoring-apm.md). - -`apm-server.register.ingest.pipeline.enabled` -: Loads the pipeline definitions to Elasticsearch when the APM Server starts up. Defaults to `false`. - -`apm-server.register.ingest.pipeline.overwrite` -: Overwrites the existing pipeline definitions in Elasticsearch. Defaults to `true`. - -`apm-server.rum.event_rate.lru_size` -: Defines the number of unique IP addresses that can be tracked in the LRU cache, which keeps a rate limit for each of the most recently seen IP addresses. Defaults to `1000`. - -`apm-server.rum.event_rate.limit` -: Sets the rate limit per second for each IP address for events sent to the APM Server v2 RUM endpoint. Defaults to `300`. - -`apm-server.rum.enabled` -: Enables/disables Real User Monitoring (RUM) support. Defaults to `true` (enabled). - -`apm-server.rum.allow_origins` -: Specifies a list of permitted origins from user agents. The default is `*`, which allows everything. - -`apm-server.rum.library_pattern` -: Differentiates library frames against specific attributes. Refer to "Configure Real User Monitoring (RUM)" in the [Observability Guide](https://www.elastic.co/guide/en/observability/current) to learn more. The default value is `"node_modules|bower_components|~"`. - -`apm-server.rum.exclude_from_grouping` -: Configures the RegExp to be matched against a stacktrace frame’s `file_name`. - -`apm-server.rum.rate_limit` -: Sets the rate limit per second for each IP address for requests sent to the RUM endpoint. Defaults to `10`. - -`apm-server.capture_personal_data` -: When set to `true`, the server captures the IP of the instrumented service and its User Agent. Enabled by default. - -`setup.template.settings.index.number_of_shards` -: Specifies the number of shards for the Elasticsearch template. - -`setup.template.settings.index.number_of_replicas` -: Specifies the number of replicas for the Elasticsearch template. - -`apm-server.frontend.enabled` -: Enables/disables frontend support. - -`apm-server.frontend.allow_origins` -: Specifies the comma-separated list of permitted origins from user agents. The default is `*`, which allows everything. - -`apm-server.frontend.library_pattern` -: Differentiates library frames against [specific attributes](https://www.elastic.co/guide/en/apm/server/6.3/configuration-frontend.html). The default value is `"node_modules|bower_components|~"`. - -`apm-server.frontend.exclude_from_grouping` -: Configures the RegExp to be matched against a stacktrace frame’s `file_name`. - -`apm-server.frontend.rate_limit` -: Sets the rate limit per second per IP address for requests sent to the frontend endpoint. Defaults to `10`. - -`apm-server.capture_personal_data` -: When set to `true`, the server captures the IP address of the instrumented service and its User Agent. Enabled by default. - -`max_procs` -: Max number of CPUs used simultaneously. Defaults to the number of logical CPUs available. - -`setup.template.enabled` -: Set to false to disable loading of Elasticsearch templates used for APM indices. If set to false, you must load the template manually. - -`setup.template.name` -: Name of the template. Defaults to `apm-server`. - -`setup.template.pattern` -: The template pattern to apply to the default index settings. Default is `apm-*` - -`setup.template.settings.index.number_of_shards` -: Specifies the number of shards for the Elasticsearch template. - -`setup.template.settings.index.number_of_replicas` -: Specifies the number of replicas for the Elasticsearch template. - -`output.elasticsearch.bulk_max_size` -: Maximum number of events to bulk together in a single Elasticsearch bulk API request. By default, this number changes based on the size of the instance: - - | Instance size | Default max events | - | --- | --- | - | 512MB | 267 | - | 1GB | 381 | - | 2GB | 533 | - | 4GB | 762 | - | 8GB | 1067 | - - -`output.elasticsearch.indices` -: Array of index selector rules supporting conditionals and formatted string. - -`output.elasticsearch.index` -: The index to write the events to. If changed, `setup.template.name` and `setup.template.pattern` must be changed accordingly. - -`output.elasticsearch.worker` -: Maximum number of concurrent workers publishing events to Elasticsearch. By default, this number changes based on the size of the instance: - - | Instance size | Default max concurrent workers | - | --- | --- | - | 512MB | 5 | - | 1GB | 7 | - | 2GB | 10 | - | 4GB | 14 | - | 8GB | 20 | - - -`queue.mem.events` -: Maximum number of events to concurrently store in the internal queue. By default, this number changes based on the size of the instance: - - | Instance size | Default max events | - | --- | --- | - | 512MB | 2000 | - | 1GB | 4000 | - | 2GB | 8000 | - | 4GB | 16000 | - | 8GB | 32000 | - - -`queue.mem.flush.min_events` -: Minimum number of events to have before pushing them to Elasticsearch. By default, this number changes based on the size of the instance. - -`queue.mem.flush.timeout` -: Maximum duration before sending the events to the output if the `min_events` is not crossed. - - -### Logging settings [echlogging_settings] - -`logging.level` -: Specifies the minimum log level. One of *debug*, *info*, *warning*, or *error*. Defaults to *info*. - -`logging.selectors` -: The list of debugging-only selector tags used by different APM Server components. Use *** to enable debug output for all components. For example, add *publish* to display all the debug messages related to event publishing. - -`logging.metrics.enabled` -: If enabled, APM Server periodically logs its internal metrics that have changed in the last period. Defaults to *true*. - -`logging.metrics.period` -: The period after which to log the internal metrics. Defaults to *30s*. - -::::{note} -To change logging settings you must first [enable deployment logging](../../../deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md). -:::: - - - - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-manage-kibana-settings.md b/raw-migrated-files/cloud/cloud-heroku/ech-manage-kibana-settings.md deleted file mode 100644 index 45212b9174..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-manage-kibana-settings.md +++ /dev/null @@ -1,936 +0,0 @@ -# Edit Kibana user settings [ech-manage-kibana-settings] - -Elasticsearch Add-On for Heroku supports most of the standard Kibana and X-Pack settings. Through a YAML editor in the console, you can append Kibana properties to the `kibana.yml` file. Your changes to the configuration file are read on startup. - -::::{important} -Be aware that some settings that could break your cluster if set incorrectly and that the syntax might change between major versions. Before upgrading, be sure to review the full list of the [latest Kibana settings and syntax](kibana://reference/configuration-reference/general-settings.md). -:::: - - -To change Kibana settings: - -1. Log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. On the **Deployments** page, select your deployment. - - Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. - -3. From your deployment menu, go to the **Edit** page. -4. In the **Kibana** section, select **Edit user settings**. (For deployments with existing user settings, you may have to expand the **Edit kibana.yml** caret instead.) -5. Update the user settings. -6. Select **Save changes**. - -Saving your changes initiates a configuration plan change that restarts Kibana automatically for you. - -::::{note} -If a setting is not supported by Elasticsearch Add-On for Heroku, you will get an error message when you try to save. -:::: - - -## Supported Kibana settings [ech-kibana-config] - -### Version 8.12.0+ [echversion_8_12_0] - -`xpack.reporting.csv.maxConcurrentShardRequests` -: Sets the maximum number of concurrent shard requests that each sub-search request executes per node during Kibana CSV export. Defaults to `5`. - - -### Version 8.11.0+ [echversion_8_11_0] - -`xpack.action.queued.max` -: Specifies the maximum number of actions that can be queued. Defaults to `1000000`. - - -### Version 8.9.0+ [echversion_8_9_0] - -`xpack.fleet.createArtifactsBulkBatchSize` -: Allow to configure batch size for creating and updating Fleet user artifacts. Examples include creation of Trusted Applications and Endpoint Exceptions in Security. To learn more, check [Fleet settings in Kibana](kibana://reference/configuration-reference/fleet-settings.md). - -`xpack.securitySolution.maxUploadResponseActionFileBytes` -: Allow to configure the max file upload size for use with the Upload File Repsonse action available with the Defend Integration. To learn more, check [Endpoint Response actions](/solutions/security/endpoint-response-actions.md). - - -### Version 8.7.0+ [echversion_8_7_0] - -`xpack.security.session.concurrentSessions.maxSessions` -: Set the maximum number of sessions each user is allowed to have active in {{kib}}. By default, no limit is applied. If set, the value of this option should be an integer between 1 and 1000. When the limit is exceeded, the oldest session is automatically invalidated. To learn more, check [Session management](/deploy-manage/security/kibana-session-management.md#session-max-sessions). - -`server.securityResponseHeaders.crossOriginOpenerPolicy` -: Controls whether the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) header is used in all responses to the client from the Kibana server. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-crossoriginopenerpolicy). - - -### Version 8.6.0+ [echversion_8_6_0] - -`server.compression.brotli.enabled` -: Enable brotli compression format for browser-server communications. Default: false. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`xpack.fleet.enableExperimental` -: Allow to configure experimental feature for Fleet. To learn more, check [Fleet settings in Kibana](kibana://reference/configuration-reference/fleet-settings.md). - - -### Version 8.4.0+ [echversion_8_4_0] - -`migrations.discardUnknownObjects` -: Discard saved objects with unknown types during a migration. Must be set to the target version, e.g.: `8.4.0`. Default: undefined. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`migrations.discardCorruptObjects` -: Discard corrupt saved objects, as well as those that cause transform errors during a migration. Must be set to the target version, e.g.: `8.4.0`. Default: undefined. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - - -### Version 8.3.0+ [echversion_8_3_0] - -`elasticsearch.compression` -: Enable compression for communications with Elasticsearch. Default: false. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - - -### Version 8.2.0+ [echversion_8_2_0] - -`elasticsearch.maxSockets` -: The maximum number of sockets that can be used for communications with Elasticsearch. Default: Infinity. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - - -### Version 8.1.0+ [echversion_8_1_0] - -`execution_context.enabled` -: Propagate request-specific metadata to Elasticsearch server by way of the `x-opaque-id` header. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - - -### Supported versions before 8.x [echsupported_versions_before_8_x] - -`vis_type_table.legacyVisEnabled` -: For 7.x versions version 7.11 and higher, a new version of the datatable visualization is used. Set to `true` to enable the legacy version. In version 8.0, the old implementation is removed and this setting is no longer supported. - -`vega.enableExternalUrls` -: Set to `true` to allow Vega vizualizations to use data from sources other than the linked Elasticsearch cluster. In stack version 8.0 and above, the `vega.enableExternalUrls` is not supported. Use `vis_type_vega.enableExternalUrls` instead. - - -### All supported versions [echall_supported_versions_2] - -`migrations.maxBatchSizeBytes` -: Defines the maximum payload size for indexing batches of saved objects during upgrade migrations. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`server.maxPayload` -: The maximum payload size in bytes for incoming server requests. Default: 1048576. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-maxpayload). - -`server.securityResponseHeaders.strictTransportSecurity` -: Controls whether the [`Strict-Transport-Security`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) header is used in all responses to the client from the Kibana server. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-stricttransportsecurity). - -`server.securityResponseHeaders.xContentTypeOptions` -: Controls whether the [`X-Content-Type-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) header is used in all responses to the client from the Kibana server. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-xcontenttypeoptions). - -`server.securityResponseHeaders.referrerPolicy` -: Controls whether the [`Referrer-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) header is used in all responses to the client from the Kibana server. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-referrerpolicy). - -`server.securityResponseHeaders.permissionsPolicy` -: Controls whether the `Permissions-Policy` header is used in all responses to the client from the Kibana server. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-permissionspolicy). - -`server.securityResponseHeaders.permissionsPolicyReportOnly` -: Controls whether the `Permissions-Policy-Report-Only` header is used in all responses to the client from the Kibana server. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-permissionspolicy). - -`server.securityResponseHeaders.disableEmbedding` -: Controls whether the [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) and [`X-Frame-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) headers are configured to disable embedding Kibana in other webpages using iframes. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-disableembedding). - -`data.autocomplete.valueSuggestions.timeout` -: Specifies the time in milliseconds to wait for autocomplete suggestions from Elasticsearch. The default is 1000. Allowed values are between 1 and 1200000. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`data.autocomplete.valueSuggestions.terminateAfter` -: Specifies the max number of documents loaded by each shard to generate autocomplete suggestions. The default is 100000. Allowed values are between 1 and 10000000. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`map.tilemap.options.attribution` -: Adds the map attribution string. - -`map.tilemap.options.maxZoom` -: Sets the maximum zoom level. - -`map.tilemap.options.minZoom` -: Sets the minimum zoom level. - -`map.tilemap.options.subdomains` -: Provides an array of subdomains used by the tile service. Specify the position of the subdomain the URL with the token `{s}`. - -`map.tilemap.url` -: Lists the URL to the tileservice that Kibana uses to display map tiles in tilemap visualizations. - -`i18n.locale` -: Specifies the locale for all strings, dates, and number formats that can be localized. Defaults to `en` (English). - -`migrations.batchSize` -: Defines the number of documents migrated at a time during saved object upgrade migrations. To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md). - -`server.defaultRoute` -: Specifies the default route when opening Kibana. You can use this setting to modify the landing page when opening Kibana. - -`server.customResponseHeaders` -: Specifies HTTP header names and values that the Kibana backend will return to the client. - -#### Map settings [echmap_settings] - -`map.regionmap:` -: Specifies additional vector layers for use in [Region Map](https://www.elastic.co/guide/en/kibana/7.5/visualize-maps.html#region-map) visualizations. Each layer object points to an external vector file that contains a geojson FeatureCollection. The file must use the [WGS84 coordinate reference system](https://en.wikipedia.org/wiki/World_Geodetic_System) and only include polygons. If the file is hosted on a separate domain from Kibana, the server needs to be CORS-enabled so Kibana can download the file. The following example shows a valid regionmap configuration. - - ```yaml - map.regionmap: - includeElasticMapsService: false - layers: - - name: "Departments of France" - url: "http://my.cors.enabled.server.org/france_departements.geojson" - attribution: "INRAP" - fields: - - name: "department" - description: "Full department name" - - name: "INSEE" - description: "INSEE numeric identifier" - ``` - - -`map.regionmap.includeElasticMapsService:` -: Turns on or off whether layers from the Elastic Maps Service should be included in the vector layer option list. Supported on Elastic Cloud Enterprise. By turning this off, only the layers that are configured here will be included. The default is `true`. - -`map.regionmap.layers[].attribution:` -: Optional. References the originating source of the geojson file. - -`map.regionmap.layers[].fields[]:` -: Mandatory. Each layer can contain multiple fields to indicate what properties from the geojson features you wish to expose. The previous example shows how to define multiple properties. - -`map.regionmap.layers[].fields[].description:` -: Mandatory. The human readable text that is shown under the Options tab when building the Region Map visualization. - -`map.regionmap.layers[].fields[].name:` -: Mandatory. This value is used to do an inner-join between the document stored in Elasticsearch and the geojson file. For example, if the field in the geojson is called `Location` and has city names, there must be a field in Elasticsearch that holds the same values that Kibana can then use to lookup for the geoshape data. - -`map.regionmap.layers[].name:` -: Mandatory. A description of the map being provided. - -`map.regionmap.layers[].url:` -: Mandatory. The location of the geojson file as provided by a webserver. - -`tilemap.options.attribution` -: Adds the map attribution string. - -`tilemap.options.maxZoom` -: Sets the maximum zoom level. - -`tilemap.options.minZoom` -: Sets the minimum zoom level. - -`tilemap.options.subdomains` -: Provides an array of subdomains used by the tile service. Specify the position of the subdomain the URL with the token `{s}`. - -`tilemap.url` -: Lists the URL to the tileservice that Kibana uses to display map tiles in tilemap visualizations. - - - -### SAML settings [echsaml_settings] - -If you are using SAML to secure your clusters, these settings are supported in Elasticsearch Add-On for Heroku. - -To learn more, refer to [configuring Kibana to use SAML](/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md#saml-configure-kibana). - -#### Version 8.0.0+ [echversion_8_0_0] - -The following additional setting is supported: - -`server.xsrf.allowlist` -: Allows the SAML authentication URL within Kibana, so that the Kibana server doesn’t reject external authentication messages that originate from your Identity Provider. - - -#### All supported versions [echall_supported_versions_3] - -`xpack.security.authc.providers.saml..useRelayStateDeepLink` -: Specifies if Kibana should treat the `RelayState` parameter as a deep link when Identity Provider Initiated login flow is used. - -`xpack.security.authc.providers.saml..order` -: Specifies order of the SAML authentication provider in the authentication chain. - -`xpack.security.authc.providers.saml..realm` -: Specifies which SAML realm in Elasticsearch should be used. - -`xpack.security.authc.providers.saml..maxRedirectURLSize` -: Specifies the maximum size of the URL that Kibana is allowed to store during the SAML handshake. - -`xpack.security.authc.providers.saml..description` -: Specifies how SAML login should be titled in the Login Selector UI. - -`xpack.security.authc.saml.maxRedirectURLSize` -: Specifies the maximum size of the URL that Kibana is allowed to store during the SAML handshake. - -`xpack.security.authc.saml.realm` -: Specifies which SAML realm in Elasticsearch should be used. - -`xpack.security.authc.providers` -: Specifies which providers are going to be used in Kibana. - - -#### All supported versions before 8.x [echall_supported_versions_before_8_x] - -`xpack.security.authProviders` -: Set to `saml` to instruct Kibana to use SAML SSO as the authentication method. - -`xpack.security.public.protocol` -: Set to HTTP or HTTPS. To access Kibana, HTTPS protocol is recommended. - -`xpack.security.public.hostname` -: Set to a fully qualified hostname to connect your users to the proxy server. - -`xpack.security.public.port` -: The port number that connects your users to the proxy server (for example, 80 for HTTP or 443 for HTTPS). - -`xpack.security.authc.saml.useRelayStateDeepLink` -: Specifies if Kibana should treat the `RelayState` parameter as a deep link when Identity Provider Initiated login flow is used. - -`server.xsrf.whitelist` -: Explicitly allows the SAML authentication URL within Kibana, so that the Kibana server doesn’t reject external authentication messages that originate from your Identity Provider. This setting is renamed to `server.xsrf.allowlist` in version 8.0.0. - - - -### OpenID Connect [echopenid_connect] - -If you are using OpenID Connect to secure your clusters, these settings are supported in Elasticsearch Add-On for Heroku. - -`xpack.security.authc.providers.oidc..order` -: Specifies order of the OpenID Connect authentication provider in the authentication chain. - -`xpack.security.authc.providers.oidc..realm` -: Specifies which OpenID Connect realm in Elasticsearch should be used. - -`xpack.security.authc.providers.oidc..description` -: Specifies how OpenID Connect login should be titled in the Login Selector UI. - -`xpack.security.authc.oidc.realm` -: Specifies which OpenID Connect realm in Elasticsearch should be used. - -To learn more, check [configuring Kibana to use OpenID Connect](/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md). - - -### Anonymous authentication [echanonymous_authentication] - -If you want to allow anonymous authentication in Kibana, these settings are supported in Elasticsearch Add-On for Heroku. To learn more on how to enable anonymous access, check [Enabling anonymous access](/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md) and [Configuring Kibana to use anonymous authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#anonymous-authentication). - -#### Supported versions before 8.0.0 [echsupported_versions_before_8_0_0] - -`xpack.security.sessionTimeout` -: Specifies the session duration in milliseconds. Allows a value between 15000 (15 seconds) and 86400000 (1 day). To learn more, check [Security settings in Kibana](kibana://reference/configuration-reference/security-settings.md). Deprecated in versions 7.6+ and removed in versions 8.0+. - - -#### All supported versions [echall_supported_versions_4] - -`xpack.security.authc.anonymous.*` -: Enables access for the `anonymous` user. In versions prior to 7.10 anonymous access is enabled by default, but you can add this setting if you want to avoid anonymous access being disabled accidentally by a subsequent upgrade. - -`xpack.security.authc.providers.anonymous..order` -: Specifies order of the anonymous authentication provider in the authentication chain. - -`xpack.security.authc.providers.anonymous..credentials` -: Specifies which credentials Kibana should use for anonymous users. - - - - -## X-Pack configuration settings [ech-xpack-config] - -You can configure the following X-Pack settings from the Kibana **User Settings** editor. - -### Version 8.18+ [echversion_8_18] - -`xpack.fleet.enableManagedLogsAndMetricsDataviews` -: Allow to disable the automatic creation of global dataviews `logs-*` and `metrics-*`. - - -### Version 8.16+ [echversion_8_16] - -`xpack.task_manager.capacity` -: Controls the number of tasks that can be run at one time. Can be minimum 5 and maximum 50. Default: 10. - - -### Version 8.8+ [echversion_8_8] - -`xpack.cases.files.allowedMimeTypes` -: The MIME types that you can attach to a case, represented in an array of strings. For example: `['image/tiff','text/csv','application/zip'].` The default MIME types are specified in [mime_types.ts](https://github.com/elastic/kibana/blob/8.16/x-pack/plugins/cases/common/constants/mime_types.ts). - -`xpack.cases.files.maxSize` -: The size limit for files that you can attach to a case, represented as the number of bytes. By default, the limit is 10 MiB for images and 100 MiB for all other MIME types. If you specify a value for this setting, it affects all file types. - -`xpack.actions.enableFooterInEmail` -: A boolean value indicating that a footer with a relevant link should be added to emails sent as alerting actions. Default: true. - - -### Version 8.7+ [echversion_8_7] - -`xpack.actions.run.maxAttempts` -: Specifies the maximum number of times an action can be attempted to run. Can be minimum 1 and maximum 10. - -`xpack.actions.run.connectorTypeOverrides` -: Overrides the settings under xpack.actions.run for a connector type with the given ID. For example id:'.server-log', maxAttempts:5. - - -### Version 8.6+ [echversion_8_6] - -`xpack.task_manager.monitored_stats_health_verbose_log.level` -: Set to `info` for Task Manager to log the health monitoring stats at info level instead of `debug`. Default: `debug`. - - -### Version 8.5+ [echversion_8_5] - -`xpack.security.accessAgreement.message` -: This setting specifies the access agreement text in Markdown format that will be used as the default access agreement for all providers that do not specify a value for `xpack.security.authc.providers...accessAgreement.message`. - -`xpack.alerting.rules.run.alerts.max` -: Sets the maximum number of alerts that a rule can generate each time detection checks run. Defaults to `1000`. - - -### Version 8.3+ [echversion_8_3] - -`xpack.cloudSecurityPosture.enabled` -: Enables the Kibana UI for Elastic’s Cloud Security Posture solution. The solution provides audit & compliance checks on Cloud & Kubernetes environments. Defaults to `false`. - -`xpack.alerting.rules.run.actions.connectorTypeOverrides` -: Overrides the settings under xpack.alerting.rules.run.actions for a connector type with the given ID. For example id:'.server-log', max:1000. - - -### Version 8.2+ [echversion_8_2] - -`xpack.alerting.rules.minimumScheduleInterval.value` -: Specifies the minimum schedule interval for rules. This minimum is applied to all rules created or updated after you set this value. Defaults to `1m`. - -`xpack.alerting.rules.minimumScheduleInterval.enforce` -: Specifies the behavior when a new or changed rule has a schedule interval less than the value defined in `xpack.alerting.rules.minimumScheduleInterval.value`. If `false`, rules with schedules less than the interval will be created but warnings will be logged. If `true`, rules with schedules less than the interval cannot be created. Default: `false`. - -`xpack.alerting.rules.run.actions.max` -: Sets the maximum number of actions that a rule can trigger each time detection checks run (maximum `100000`). - -`xpack.alerting.rules.run.timeout` -: Specifies the default timeout for the all rule types tasks. - -`xpack.alerting.rules.run.ruleTypeOverrides` -: Overrides the settings under xpack.alerting.rules.run for a rule type with the given id. e.g. (id:'index-threshold', timeout:'5m'), - -#### Version 8.1+ [echversion_8_1] - -`xpack.alerting.cancelAlertsOnRuleTimeout` -: Set to `false` to enable writing alerts and scheduling actions even if rule execution is cancelled due to timeout. Defaults to `true`. - - - -### Version 8.0+ [echversion_8_0] - -`xpack.endpoint.enabled` -: Set to `true` to enable the Endpoint application. - -`xpack.fleet.enabled` -: Set to `false` to disable the Fleet application. Also enables the EPM and Agents features. For details about using this application, check the blog post [Easier data onboarding with Elastic Agent and Ingest Manager](https://www.elastic.co/blog/introducing-elastic-agent-and-ingest-manager). - -`xpack.fleet.agents.enabled` -: Set to `false` to disable the Agents API & UI. - -`xpack.ruleRegistry.write.disabledRegistrationContexts` -: Specifies the observability alert indices that are disabled to be written. Data type is array. Allowed values are: [ *observability.logs*,*observability.metrics*,*observability.apm*,*observability.uptime* ] - - -### Version 7.17.4+, 8.3+ [echversion_7_17_4_8_3] - -`xpack.actions.email.domain_allowlist` -: A list of allowed email domains which can be used with the email connector. When this setting is not used, all email domains are allowed. When this setting is used, if any email is attempted to be sent that (a) includes an addressee with an email domain that is not in the allowlist, or (b) includes a from address domain that is not in the allowlist, it will fail with a message indicating the email is not allowed. - -::::{note} -This setting is not available in versions 8.0.0 through 8.2.0. As such, this setting should be removed before upgrading from 7.17 to 8.0, 8.1 or 8.2. It is possible to configure the settings in 7.17.4 and then upgrade to 8.3.0 directly. -:::: - - - -### Version 7.17.2+, 8.2+ [echversion_7_17_2_8_2] - -`xpack.task_manager.event_loop_delay.monitor` -: Enables event loop delay monitoring, which will log a warning when a task causes an event loop delay which exceeds the `warn_threshold` setting. Defaults to true. - - ::::{note} - This setting is not available in versions 8.0.0 through 8.1.1. - :::: - - -`xpack.task_manager.event_loop_delay.warn_threshold` -: Sets the amount of event loop delay during a task execution which will cause a warning to be logged. Defaults to 5000 milliseconds (5 seconds). - - ::::{note} - This setting is not available in versions 8.0.0 through 8.1.1. As such, this setting should be removed before upgrading from 7.17 to 8.0 or 8.1.0. It is possible to configure the settings in 7.17.2 and then upgrade to 8.2.0 directly. - :::: - - - -### All supported versions [echall_supported_versions_5] - -`xpack.alerting.defaultRuleTaskTimeout` -: Specifies the default timeout for the all rule types tasks. Defaults to `5m`. Deprecated in versions 8.2+ and removed in {{stack}} 9.0+. - -`xpack.actions.microsoftGraphApiUrl` -: Specifies the URL to the Microsoft Graph server when using the MS Exchange Server email service. Defaults to `https://graph.microsoft.com/v1.0`. - -`xpack.alerting.maxEphemeralActionsPerAlert` -: Sets the number of actions that will be executed ephemerally. Defaults to `10`. - -`xpack.task_manager.ephemeral_tasks.enabled` -: Enables an experimental feature that executes a limited (and configurable) number of actions in the same task as the alert which triggered them. These action tasks reduce the latency of the time it takes an action to run after it’s triggered, but are not persisted as SavedObjects. These non-persisted action tasks have a risk that they won’t be run at all if the Kibana instance running them exits unexpectedly. Defaults to `false`. - -`xpack.task_manager.ephemeral_tasks.request_capacity` -: Sets the size of the ephemeral queue. Defaults to `10`. - -`xpack.actions.customHostSettings` -: An array of objects, one per host, containing the SSL/TLS settings used when executing connectors which make HTTPS and SMTP connections to the host servers. For details about using this setting, check [Alerting and action settings in Kibana](kibana://reference/configuration-reference/alerting-settings.md). - -`xpack.actions.ssl.proxyVerificationMode` -: Controls the verification of the proxy server certificate that hosted-ems receives when making an outbound SSL/TLS connection to the host server. Valid values are `full`, `certificate`, and `none`. Use `full` to perform hostname verification, `certificate` to skip hostname verification, and `none` to skip verification. Default: `full`. - -`xpack.actions.ssl.verificationMode` -: Controls the verification of the server certificate that hosted-ems receives when making an outbound SSL/TLS connection to the host server. Valid values are `full`, `certificate`, and `none`. Use `full` to perform hostname verification, `certificate` to skip hostname verification, and `none` to skip verification. Default: `full`. - -`xpack.task_manager.monitored_stats_health_verbose_log.enabled` -: Enable to allow the Kibana task manager to log at either a warning or error log level if it self-detects performance issues. Default: `false`. - -`xpack.task_manager.monitored_stats_health_verbose_log.warn_delayed_task_start_in_seconds` -: The number of seconds we allow a task to delay before printing a warning server log. Default: `60`. - -`xpack.actions.preconfiguredAlertHistoryEsIndex` -: Set to `true` to enable experimental Alert history Elasticsearch index connector. Default: `false`. - -`xpack.discoverEnhanced.actions.exploreDataInContextMenu.enabled` -: Set to `true` to enable the "explore underlying data" menu action in dashboards. Default: `false`. - -`xpack.actions.proxyBypassHosts` -: Specifies hostnames which should not use the proxy, if using a proxy for actions. The value is an array of hostnames as strings. By default, all hosts will use the proxy. The settings `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` cannot be used at the same time. - -`xpack.actions.proxyOnlyHosts` -: Specifies hostnames which should only be used with the proxy, if using a proxy for actions. The value is an array of hostnames as strings. By default, all hosts will use the proxy. The settings `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` cannot be used at the same time. - -`xpack.actions.maxResponseContentLength` -: Specifies the max number of bytes of the HTTP response for requests to external resources. Defaults to *1mb*. - -`xpack.actions.responseTimeout` -: Specifies the time allowed for requests to external resources. Requests that take longer are aborted. The time is formatted as [ms|s|m|h|d|w|M|Y], for example, *20m*, *24h*, *7d*, *1w*. Defaults to *60s*. - -`xpack.task_manager.monitored_task_execution_thresholds` -: Specifies the thresholds for failed task executions. If the percentage of failed executions exceeds the specified thresholds, the health of the task will be reported as configured. Can be specified at a default level or a custom level for specific task types. The following example shows a valid `monitored_task_execution_thresholds configuration`. - - ```yaml - xpack.task_manager.monitored_task_execution_thresholds: - default: - error_threshold: 70 - warn_threshold: 50 - custom: - "alerting:.index-threshold": - error_threshold: 50 - warn_threshold: 0 - ``` - - -`xpack.task_manager.version_conflict_threshold` -: Specifies the threshold for version conflicts. If the percentage of version conflicts exceeds the threshold, the task manager `poll_interval` will automatically be adjusted. Default: `80`. - -`xpack.actions.proxyUrl` -: Specifies the proxy URL to use, if using a proxy for actions. - -`xpack.actions.proxyHeaders` -: Specifies headers for proxy, if using a proxy for actions. - -`xpack.ingestManager.enabled` -: Set to `false` to disable the Ingest Manager application. Also enables the EPM and Fleet features. For details about using this application, check the blog post [Easier data onboarding with Elastic Agent and Ingest Manager](https://www.elastic.co/blog/introducing-elastic-agent-and-ingest-manager). - -`xpack.ingestManager.fleet.enabled` -: Set to `false` to disable the Fleet API & UI. - -`xpack.lists.maxImportPayloadBytes` -: Sets the number of bytes (default `9000000`, maximum `100000000`) allowed for uploading Security Solution value lists. For every 10 megabytes, it is recommended to have an additional 1 gigabyte of RAM reserved for Kibana. For example, on a Kibana instance with 2 gigabytes of RAM, you can set this value up to 20000000 (20 megabytes). - -`xpack.lists.importBufferSize` -: Sets the buffer size used for uploading Security Solution value lists (default `1000`). Change the value if you are experiencing slow upload speeds or larger than wanted memory usage when uploading value lists. Set to a higher value to increase throughput at the expense of using more Kibana memory, or a lower value to decrease throughput and reduce memory usage. - -`xpack.security.sameSiteCookies` -: Sets the `SameSite` attribute of `Set-Cookie` HTTP header. It allows you to declare whether your cookie should be restricted to a first-party or same-site context. **Not set** by default, which makes modern browsers treat it as `Lax`. If you use Kibana embedded in an iframe in modern browsers, you might need to set it to `None`. Note that `None` usage requires secure context: `xpack.security.secureCookies: true`. Some old versions of IE11 do not support `SameSite: None`, so you should not specify `xpack.security.sameSiteCookies` at all. - -`xpack.ingestManager.enabled` -: Set to `true` (default `false`) to enable the Ingest Manager application. Also enables the EPM and Fleet features. For details about using this application, check the blog post [Easier data onboarding with Elastic Agent and Ingest Manager](https://www.elastic.co/blog/introducing-elastic-agent-and-ingest-manager). - -`xpack.ingestManager.epm.enabled` -: Set to `true` (default) to enable the EPM API & UI. - -`xpack.ingestManager.fleet.enabled` -: Set to `true` (default) to enable the Fleet API & UI. - -`xpack.task_manager.max_workers` -: Specify the maximum number of tasks a Kibana will run concurrently. Default: `10`. Deprecated in versions 8.16+ - -`xpack.task_manager.poll_interval` -: Specify how often, in milliseconds, a Kibana should check for more tasks. Default: `3000`. - -`xpack.eventLog.logEntries` -: Set to `true` to enable logging event log documents from alerting to the Kibana log, in addition to being indexed into the event log index. Default: `false`. - -`xpack.security.session.idleTimeout` -: Set the session duration. The format is a string of `count` and `unit`, where unit is one of `ms`,`s`,`m`,`h`,`d`,`w`,`M`,`Y`. For example, `70ms`, `5s`, `3d`, `1Y`. To learn more, check [Security settings in Kibana](kibana://reference/configuration-reference/security-settings.md). - -`xpack.security.session.lifespan` -: Sets the maximum duration, also known as "absolute timeout". After this duration, the session will expire even if it is not idle. To learn more, check [Security settings in Kibana](kibana://reference/configuration-reference/security-settings.md). - -`xpack.maps.showMapVisualizationTypes` -: Set to `true` if you want to create new region map visualizations. - -`xpack.actions.allowedHosts` -: Set to an array of host names which actions such as email, slack, pagerduty, and webhook can connect to. An element of `*` indicates any host can be connected to. An empty array indicates no hosts can be connected to. Default: `[ * ]` - -`xpack.actions.enabledActionTypes` -: Set to an array of action types that are enabled. An element of `*` indicates all action types registered are enabled. The action types provided by Kibana are: `.server-log`, `.slack`, `.email`, `.index`, `.pagerduty`, `.webhook`. Default: `[ * ]` - -`xpack.grokdebugger.enabled` -: Set to `true` (default) to enable the Grok Debugger. - -`xpack.graph.enabled` -: Set to `false` to disable X-Pack graph. - -`xpack.monitoring.cluster_alerts.email_notifications.email_address` -: When enabled, specifies the email address to receive cluster alert notifications. - -`xpack.monitoring.kibana.collection.interval` -: Controls [how often data samples are collected](elasticsearch://reference/elasticsearch/configuration-reference/monitoring-settings.md#monitoring-collection-settings). - -`xpack.monitoring.min_interval_seconds` -: Specifies the minimum number of seconds that a time bucket in a chart can represent. If you modify the `xpack.monitoring.kibana.collection.interval`, use the same value in this setting. - -`xpack.monitoring.ui.container.elasticsearch.enabled` -: For Elasticsearch clusters that run in containers, enables the `Node Listing` to display the `CPU utilization` based on the `Cgroup statistics`, and adds the `Cgroup CPU utilization` to the Node Overview page instead of the overall operating system CPU utilization. - -`xpack.ml.enabled` -: Set to true (default) to enable machine learning. - - If set to `false` in `kibana.yml`, the machine learning icon is hidden in this Kibana instance. If `xpack.ml.enabled` is set to `true` in `elasticsearch.yml`, however, you can still use the machine learning APIs. To disable machine learning entirely, check the [Elasticsearch Machine Learning Settings](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md). - - -#### Content security policy configuration [echcontent_security_policy_configuration] - -`csp.script_src` -: Add sources for the [Content Security Policy `script-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src). When [`csp.strict`](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#csp-strict) is `true`, `csp.script_src` may not be `unsafe-inline`. Rules may not contain `nonce-*` or `none` and will not override the defaults. **Default: [`'unsafe-eval'`, `'self'`]** - -`csp.worker_src` -: Add sources for the [Content Security Policy `worker-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src). Rules may not contain `nonce-*` or `none` and will not override the defaults. **Default: [`blob:`, `'self'`]** - -`csp.style_src` -: Add sources for the [Content Security Policy `style-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src). Rules may not contain `nonce-*` or `none` and will not override the defaults. **Default: [`'unsafe-inline'`, `'self'`]** - -`csp.connect_src` -: Add sources for the [Content Security Policy `connect-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src). - -`csp.default_src` -: Add sources for the [Content Security Policy `default-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src). - -`csp.font_src` -: Add sources for the [Content Security Policy `font-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/font-src). - -`csp.frame_src` -: Add sources for the [Content Security Policy `frame-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-src). - -`csp.img_src` -: Add sources for the [Content Security Policy `img-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src). - -`csp.report_uri` -: Add sources for the [Content Security Policy `report-uri` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-uri). - -`csp.report_only.form_action` -: Add sources for the [Content Security Policy `form-action` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action) in reporting mode. - -$$$csp-strict$$$ `csp.strict` -: Blocks Kibana access to any browser that does not enforce even rudimentary CSP rules. In practice, this disables support for older, less safe browsers like Internet Explorer. **Default: `true`** To learn more, check [Configure Kibana](kibana://reference/configuration-reference/general-settings.md)]. - -`csp.warnLegacyBrowsers` -: Shows a warning message after loading Kibana to any browser that does not enforce even rudimentary CSP rules, though Kibana is still accessible. This configuration is effectively ignored when [`csp.strict`](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#csp-strict) is enabled. **Default: `true`** - -`csp.disableUnsafeEval` -: [preview] Set this to `true` to remove the [`unsafe-eval`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_eval_expressions) source expression from the `script-src` directive. **Default: `false`** - - By enabling `csp.disableUnsafeEval`, Kibana will use a custom version of the Handlebars template library which doesn’t support [inline partials](https://handlebarsjs.com/guide/partials.md#inline-partials). Handlebars is used in various locations in the Kibana frontend where custom templates can be supplied by the user when for instance setting up a visualisation. If you experience any issues rendering Handlebars templates after turning on `csp.disableUnsafeEval`, or if you rely on inline partials, please revert this setting to `false` and [open an issue](https://github.com/elastic/kibana/issues/new/choose) in the Kibana GitHub repository. - - - -#### Permissions policy configuration [echpermissions_policy_configuration] - -`permissionsPolicy.report_to` -: Add sources for the permissions policy `report-to` directive. To learn more, see [Configure Kibana](kibana://reference/configuration-reference/general-settings.md#server-securityresponseheaders-permissionspolicy) - - -#### Banner settings [echbanner_settings] - -Banners are disabled by default. You need to manually configure them in order to use the feature. - -`xpack.banners.placement` -: Set to `top` to display a banner above the Elastic header. Defaults to `disabled`. - -`xpack.banners.textContent` -: The text to display inside the banner, either plain text or Markdown. - -`xpack.banners.textColor` -: The color for the banner text. Defaults to `#8A6A0A`. - -`xpack.banners.backgroundColor` -: The color of the banner background. Defaults to `#FFF9E8`. - -`xpack.banners.disableSpaceBanners` -: If true, per-space banner overrides are disabled. Defaults to `false`. - - - - -## Reporting settings [echreporting_settings] - -### Version 8.13.0+ [echversion_8_13_0] - -`xpack.reporting.csv.scroll.strategy` -: Choose the API method used to page through data during CSV export. Valid options are `scroll` and `pit`. Defaults to `pit`. - -::::{note} -Each method has its own unique limitations which are important to understand. - -* Scroll API: Search is limited to 500 shards at the very most. In cases where data shards are unavailable or time out, the export may return partial data. -* PIT API: Permissions to read data aliases alone will not work. The permissions are needed on the underlying indices or data streams. In cases where data shards are unavailable or time out, the export will be empty instead of returning partial data. - -:::: - - -`xpack.reporting.csv.scroll.duration` -: Amount of [time](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units) allowed before {{kib}} cleans the scroll context during a CSV export. Valid option is either `auto` or [time](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units), Defaults to `30s`. - -::::{note} -Support for the The option `auto` was included here, when the config value is set to `auto` the scroll context will be preserved for as long as is possible, before the report task is terminated due to the limits of `xpack.reporting.queue.timeout`. - -:::: - - - -### All supported versions [echall_supported_versions_6] - -`xpack.reporting.enabled` -: Set to `false` to completely disable reporting. - -`xpack.reporting.queue.timeout` -: Specifies the time each worker has to produce a report. If your machine is slow or under heavy load, you might need to increase this timeout. Specified in milliseconds (number) or duration (string). Duration is a string value formatted as [ms|s|m|h|d|w|M|Y], for example, *20m*, *24h*, *7d*, *1w*. - - Defaults to `120000` (2 minutes) - - -`xpack.reporting.capture.maxAttempts` -: Specifies how many retries to attempt in case of occasional failures. - - Defaults to `3`. - - -`xpack.screenshotting.capture.timeouts.openUrl` -: Specify how long to allow the Reporting browser to wait for the "Loading…​" screen to dismiss and find the initial data for the Kibana page. If the time is exceeded, a page screenshot is captured showing the current state, and the download link shows a warning message. - - Defaults to `30000` (30 seconds). - - -`xpack.screenshotting.capture.timeouts.waitForElements` -: Specify how long to allow the Reporting browser to wait for all visualization panels to load on the Kibana page. If the time is exceeded, a page screenshot is captured showing the current state, and the download link shows a warning message. - - Defaults to `30000` (30 seconds). - - -`xpack.screenshotting.capture.timeouts.renderComplete` -: Specify how long to allow the Reporting browser to wait for all visualizations to fetch and render the data. If the time is exceeded, a page screenshot is captured showing the current state, and the download link shows a warning message. - - Defaults to `30000` (30 seconds). - - -`xpack.screenshotting.capture.browser.type` -: Specifies the browser to use to capture screenshots. Valid options are `phantom` and `chromium`. - - Beginning with version 7.0, `chromium` is the only allowed option. Defaults to `phantom` for earlier versions. - - -`xpack.reporting.csv.maxSizeBytes` -: Sets the maximum size of a CSV file before being truncated. This setting exists to prevent large exports from causing performance and storage issues. Until 7.15, maximum allowed value is 50 MB (52428800 Bytes). - - Defaults to `250MB`. {{stack}} versions before 8.10 default to `10485760` (10MB). - - -`xpack.reporting.encryptionKey` -: Set to any text string. To provide your own encryption key for reports, use this setting. - -`xpack.reporting.roles.enabled` -: When `true`, grants users access to the {{report-features}} when they are assigned the `reporting_user` role. Granting access to users this way is deprecated. Set to `false` and use [Kibana privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md) instead. - -Defaults to `true`. - -`xpack.reporting.csv.scroll.duration` -: Amount of [time](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units) allowed before {{kib}} cleans the scroll context during a CSV export. - -Defaults to `30s` (30 seconds). - -::::{note} -If search latency in {{es}} is sufficiently high, such as if you are using cross-cluster search or frozen tiers, you may need to increase the setting. - -:::: - - -`xpack.reporting.csv.scroll.size` -: Sets the number of documents retrieved from {{es}} for each scroll iteration during Kibana CSV export. Defaults to `500`. - -`xpack.reporting.csv.checkForFormulas` -: Enables a check that warns you when there’s a potential formula included in the output (=, -, +, and @ chars). See OWASP: [https://www.owasp.org/index.php/CSV_Injection](https://www.owasp.org/index.php/CSV_Injection). Defaults to `true`. - -`xpack.reporting.csv.escapeFormulaValues` -: Escapes formula values in cells with a `'`. See OWASP: [https://www.owasp.org/index.php/CSV_Injection](https://www.owasp.org/index.php/CSV_Injection). Defaults to `true`. - -`xpack.reporting.csv.useByteOrderMarkEncoding` -: Adds a byte order mark (`\ufeff`) at the beginning of the CSV file. Defaults to `false`. - - - -## Logging and audit settings [echlogging_and_audit_settings] - -::::{note} -To change logging settings or to enable auditing you must first [enable deployment logging](../../../deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md). -:::: - - -The following logging settings are supported: - -### Version 8.0+ [echversion_8_0_2] - -`logging.root.level` -: Can be used to adjust Kibana’s logging level. Allowed values are `fatal`, `error`, `warn`, `info`, `debug`, `trace`, and `all`. Setting this to `all` causes all events to be logged, including system usage information, all requests, and Elasticsearch queries. This has a similar effect to enabling both `logging.verbose` and `elasticsearch.logQueries` in older 7.x versions. Setting to `error` has a similar effect to enabling `logging.quiet` in older 7.x versions. Defaults to `info`. - -`xpack.security.audit.enabled` -: When set to *true*, audit logging is enabled for security events. Defaults to *false*. - - -### Supported 7.x versions [echsupported_7_x_versions] - -`xpack.security.audit.appender.type` -: When set to *"rolling-file"* and `xpack.security.audit.enabled` is set to *true*, Kibana ECS audit logs are enabled. Beginning with version 8.0, this setting is no longer necessary for ECS audit log output; it’s only necessary to set `xpack.security.audit.enabled` to `true` - -`logging.verbose` -: If set to *true*, all events are logged, including system usage information and all requests. Defaults to *false*. - -`logging.quiet` -: If set to *true*, all logging output other than error messages is suppressed. Defaults to *false*. - -`elasticsearch.logQueries` -: When set to *true*, queries sent to Elasticsearch are logged (requires `logging.verbose` set to *true*). Defaults to *false*. - -`xpack.security.audit.enabled` -: When set to *true*, audit logging is enabled for security events. Defaults to *false*. - - -### All supported versions [echall_supported_versions_7] - -`xpack.security.audit.ignore_filters` -: List of filters that determine which audit events should be excluded from the ECS audit log. - -`xpack.security.audit.ignore_filters.actions` -: List of values matched against the `event.action` field of an audit event. - -`xpack.security.audit.ignore_filters.categories` -: List of values matched against the `event.category` field of an audit event. - -`xpack.security.audit.ignore_filters.outcomes` -: List of values matched against the `event.outcome` field of an audit event. - -`xpack.security.audit.ignore_filters.spaces` -: List of values matched against the `kibana.space_id` field of an audit event. This represents the space id in which the event took place. - -`xpack.security.audit.ignore_filters.types` -: List of values matched against the `event.type` field of an audit event. - - -### Version 8.15.0+ [echversion_8_15_0] - -`xpack.security.audit.ignore_filters.users` -: List of values matched against the `user.name` field of an audit event. This represents the username associated with the audit event. - - - -## APM [echapm] - -The following APM settings are supported in Kibana: - -### Version 8.0.0+ [echversion_8_0_0_2] - -`xpack.apm.autoCreateApmDataView` -: Set to `false` to disable the automatic creation of the APM data view when the APM app is opened. Defaults to `true`. This setting was called `xpack.apm.autocreateApmIndexPattern` in versions prior to 8.0.0. - - -### Version 7.16.0 to 8.6.2 [echversion_7_16_0_to_8_6_2] - -`xpack.apm.ui.transactionGroupBucketSize` -: Number of top transaction groups displayed in the APM app. Defaults to `1000`. - - -### Version 7.16.0 to 8.0.0 [echversion_7_16_0_to_8_0_0] - -`xpack.apm.maxServiceEnvironments` -: Maximum number of unique service environments recognized by the UI. Defaults to `100`. - - -### Supported versions before 8.x [echsupported_versions_before_8_x_2] - -`xpack.apm.autocreateApmIndexPattern` -: Set to `false` to disable the automatic creation of the APM data view when the APM app is opened. Defaults to `true`. This setting is renamed to `xpack.apm.autoCreateApmDataView` in version 8.0.0. - - -### All supported versions [echall_supported_versions_8] - -`xpack.apm.serviceMapFingerprintBucketSize` -: Maximum number of unique transaction combinations sampled for generating service map focused on a specific service. Defaults to `100`. - -`xpack.apm.serviceMapFingerprintGlobalBucketSize` -: Maximum number of unique transaction combinations sampled for generating the global service map. Defaults to `100`. - -`xpack.apm.serviceMapEnabled` -: Set to `false` to disable service maps. Defaults to `true`. - -`xpack.apm.serviceMapTraceIdBucketSize` -: Maximum number of trace IDs sampled for generating service map focused on a specific service. Defaults to `65`. - -`xpack.apm.serviceMapTraceIdGlobalBucketSize` -: Maximum number of trace IDs sampled for generating the global service map. Defaults to `6`. - -`xpack.apm.serviceMapMaxTracesPerRequest` -: Maximum number of traces per request for generating the global service map. Defaults to `50`. - -`xpack.observability.annotations.index` -: Index name where Observability annotations are stored. Defaults to `observability-annotations`. - -`xpack.apm.metricsInterval` -: Sets a `fixed_interval` for date histograms in metrics aggregations. Defaults to `30`. - -`xpack.apm.agent.migrations.enabled` -: Set to `false` to disable cloud APM migrations. Defaults to `true`. - -`xpack.apm.indices.span` -: Matcher for indices containing span documents. Defaults to apm-*. - -`xpack.apm.indices.error` -: Matcher for indices containing error documents. Defaults to apm-*. - -`xpack.apm.indices.transaction` -: Matcher for indices containing transaction documents. Defaults to apm-*. - -`xpack.apm.indices.onboarding` -: Matcher for all onboarding indices. Defaults to apm-*. - -`xpack.apm.indices.metric` -: Matcher for all metrics indices. Defaults to apm-*. - -`xpack.apm.indices.sourcemap` -: Matcher for all source map indices. Defaults to apm-*. - -`xpack.apm.maxSuggestions` -: Maximum number of suggestions fetched in autocomplete selection boxes. Defaults to `100` - -`xpack.apm.searchAggregatedTransactions` -: Whether to use metric instead of transaction documents to render the UI. Available options are `always`, `never` or `auto`. Defaults to `auto`. - -`xpack.apm.ui.maxTraceItems` -: Maximum number of child items displayed when viewing trace details. - - Defaults to `1000`. Any positive value is valid. To learn more, check [APM settings in Kibana](kibana://reference/configuration-reference/apm-settings.md). - - -`xpack.apm.ui.enabled` -: Set to `false` to disable X-Pack APM UI. diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-planning.md b/raw-migrated-files/cloud/cloud-heroku/ech-planning.md deleted file mode 100644 index a4629cf49c..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-planning.md +++ /dev/null @@ -1,55 +0,0 @@ -# Plan for production [ech-planning] - -Elasticsearch Add-On for Heroku supports a wide range of configurations. With such flexibility comes great freedom, but also the first rule of deployment planning: Your deployment needs to be matched to the workloads that you plan to run on your {{es}} clusters and {{kib}} instances. Specifically, this means two things: - -* [Does your data need to be highly available?](../../../deploy-manage/production-guidance/plan-for-production-elastic-cloud.md#ech-ha) -* [Do you know when to scale?](../../../deploy-manage/production-guidance/plan-for-production-elastic-cloud.md#ech-workloads) - - -## Does your data need to be highly available? [ech-ha] - -With Elasticsearch Add-On for Heroku, your deployment can be spread across as many as three separate availability zones, each hosted in its own, separate data center. Why this matters: - -* Data centers can have issues with availability. Internet outages, earthquakes, floods, or other events could affect the availability of a single data center. With a single availability zone, you have a single point of failure that can bring down your deployment. -* Multiple availability zones help your deployment remain available. This includes your {{es}} cluster, provided that your cluster is sized so that it can sustain your workload on the remaining data centers and that your indices are configured to have at least one replica. -* Multiple availability zones enable you to perform changes to resize your deployment with zero downtime. - -We recommend that you use at least two availability zones for production and three for mission-critical systems. Just one zone might be sufficient, if your {{es}} cluster is mainly used for testing or development and downtime is acceptable, but should never be used for production. - -With multiple {{es}} nodes in multiple availability zones you have the recommended hardware, the next thing to consider is having the recommended index replication. Each index, with the exception of searchable snapshot indexes, should have one or more replicas. Use the index settings API to find any indices with no replica: - -```sh -GET _all/_settings/index.number_of_replicas -``` - -Moreover, a high availability (HA) cluster requires at least three master-eligible nodes. For clusters that have fewer than six {{es}} nodes, any data node in the hot tier will also be a master-eligible node. So, this can be achieved by having hot nodes (serving as both data and master-eligible nodes) in three availability zones, or by having data nodes in two zones and a tiebreaker (will be automatically added if you choose two zones). For clusters that have six {{es}} nodes and beyond, dedicated master-eligible nodes are introduced. When your cluster grows, it becomes important to consider separating dedicated master-eligible nodes from dedicated data nodes. - -The data in your {{es}} clusters is also backed up every 30 minutes, 4 hours, or 24 hours, depending on which snapshot interval you choose. These regular intervals provide an extra level of redundancy. We do support [snapshot and restore](../../../deploy-manage/tools/snapshot-and-restore.md), regardless of whether you use one, two, or three availability zones. However, with only a single availability zone and in the event of an outage, it might take a while for your cluster come back online. Using a single availability zone also leaves your cluster exposed to the risk of data loss, if the backups you need are not useable (failed or partial snapshots missing the indices to restore) or no longer available by the time that you realize that you might need the data (snapshots have a retention policy). - -::::{warning} -Clusters that use only one availability zone are not highly available and are at risk of data loss. To safeguard against data loss, you must use at least two availability zones. -:::: - - -::::{warning} -Indices with no replica, except for searchable snapshot indices, are not highly available. You should use replicas to mitigate against possible data loss. -:::: - - -::::{warning} -Clusters that only have one master node are not highly available and are at risk of data loss. You must have three master-eligible nodes. -:::: - - - -## Do you know when to scale? [ech-workloads] - -Knowing how to scale your deployment is critical, especially when unexpected workloads hits. Don’t forget to [check your performance metrics](/deploy-manage/monitor/access-performance-metrics-on-elastic-cloud.md) to make sure your deployments are healthy and can cope with your workloads. - -Scaling with Elasticsearch Add-On for Heroku is easy: - -* Turn on [deployment autoscaling](../../../deploy-manage/autoscaling.md) to let Elasticsearch Add-On for Heroku manage your deployments by adjusting their available resources automatically. -* Or, if you prefer manual control, log in to the [Elasticsearch Add-On for Heroku console](https://cloud.elastic.co?page=docs&placement=docs-body), select your deployment, select **Edit deployment** from the **Actions** dropdown, and either increase the number of zones or the size per zone. - -Refer to [Sizing {{es}}: Scaling up and out](https://www.elastic.co/blog/found-sizing-elasticsearch) to identify which questions to ask yourself when determining which cluster size is the best fit for your {{es}} use case. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-regional-deployment-aliases.md b/raw-migrated-files/cloud/cloud-heroku/ech-regional-deployment-aliases.md deleted file mode 100644 index b32b2cef62..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-regional-deployment-aliases.md +++ /dev/null @@ -1,149 +0,0 @@ -# Custom endpoint aliases [ech-regional-deployment-aliases] - -Custom aliases for your deployment endpoints on Elasticsearch Add-On for Heroku allow you to have predictable, human-readable URLs that can be shared easily. An alias is unique to only one deployment within a region. - - -## Create a custom endpoint alias for a deployment [ech-create-regional-deployment-alias] - -::::{note} -New deployments are assigned a default alias derived from the deployment name. This alias can be modified later, if needed. -:::: - - -To add an alias to an existing deployment: - -1. From the **Deployments** menu, select a deployment. -2. Under **Custom endpoint alias**, select **Edit**. -3. Define a new alias. Make sure you choose something meaningful to you. - - ::::{tip} - Make the alias as unique as possible to avoid collisions. Aliases might have been already claimed by other users for deployments in the region. - :::: - -4. Select **Update alias**. - - -## Remove a custom endpoint alias [ech-delete-regional-deployment-alias] - -To remove an alias from your deployment, or if you want to re-assign an alias to another deployment, follow these steps: - -1. From the **Deployments** menu, select a deployment. -2. Under **Custom endpoint alias**, select **Edit**. -3. Remove the text from the **Custom endpoint alias** text box. -4. Select **Update alias**. - -::::{note} -After removing an alias, your organisation’s account will hold a claim on it for 30 days. After that period, other users can re-use this alias. -:::: - - - -## Using the custom endpoint URL [ech-using-regional-deployment-alias] - -To use your new custom endpoint URL to access your Elastic products, note that each has its own alias to use in place of the default application UUID. For example, if you configured the custom endpoint alias for your deployment to be `test-alias`, the corresponding alias for the Elasticsearch cluster in that deployment is `test-alias.es`. - -::::{note} -You can get the application-specific custom endpoint alias by selecting **Copy endpoint** for that product. It should contain a subdomain for each application type, for example `es`, `kb`, `apm`, or `ent`. -:::: - - - -### With the REST Client [ech-rest-regional-deployment-alias] - -* As part of the host name: - - After configuring your custom endpoint alias, select **Copy endpoint** on the deployment overview page, which gives you the fully qualified custom endpoint URL for that product. - -* As an HTTP request header: - - Alternatively, you can reach your application by passing the application-specific custom endpoint alias, for example, `test-alias.es`, as the value for the `X-Found-Cluster` HTTP header. - - - -### With the `TransportClient` [ech-transport-regional-deployment-alias] - -While the `TransportClient` is deprecated, your custom endpoint aliases still work with it. Similar to the REST Client, there are two ways to use your custom endpoint alias with the `TransportClient`: - -* As part of the host name: - - Similar to HTTP, you can find the fully qualified host on the deployment overview page by selecting **Copy endpoint** next to Elasticsearch. Make sure to remove the unnecessary `https://` prefix as well as the trailing HTTP port. - -* As part of the **Settings**: - - Include the application-specific custom endpoint alias as the value for `request.headers.X-Found-Cluster` setting in place of the `clusterId`: - - ```java - // Build the settings for our client. - String alias = "test-alias.es"; // Your application-specific custom endpoint alias here - String region = "us-east-1"; // Your region here - boolean enableSsl = true; - - Settings settings = Settings.settingsBuilder() - .put("transport.ping_schedule", "5s") - //.put("transport.sniff", false) // Disabled by default and *must* be disabled. - .put("action.bulk.compress", false) - .put("shield.transport.ssl", enableSsl) - .put("request.headers.X-Found-Cluster", alias) - .put("shield.user", "username:password") // your shield username and password - .build(); - - String hostname = alias + "." + region + ".aws.found.io"; - // Instantiate a TransportClient and add the cluster to the list of addresses to connect to. - // Only port 9343 (SSL-encrypted) is currently supported. - Client client = TransportClient.builder() - .addPlugin(ShieldPlugin.class) - .settings(settings) - .build() - .addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(hostname), 9343)); - ``` - - -For more information on configuring the `TransportClient`, see - - -## Create a custom domain with NGINX [ech-custom-domains-with-nginx] - -If you don’t get the level of domain customization you’re looking for by using the [custom endpoint aliases](../../../deploy-manage/deploy/elastic-cloud/custom-endpoint-aliases.md), you might consider creating a CNAME record that points to your Elastic Cloud endpoints. However, that can lead to some issues. Instead, setting up your own proxy could provide the desired level of customization. - -::::{important} -The setup described in the following sections is not supported by Elastic, and if your proxy cannot connect to the endpoint, but curl can, we may not be able to help. -:::: - - - -### Avoid creating CNAMEs [echavoid_creating_cnames] - -To achieve a fully custom domain, you can add a CNAME that points to your Elastic Cloud endpoint. However, this will lead to invalid certificate errors, and moreover, may simply not work. Your Elastic Cloud endpoints already point to a proxy internal to Elastic Cloud, which may not resolve your configured CNAME in the desired way. - -So what to do, instead? - - -### Setting up a proxy [echsetting_up_a_proxy] - -Here we’ll show you an example of proxying with NGINX, but this can be extrapolated to HAProxy or some other proxy server. - -You need to set `proxy_pass` and `proxy_set_header`, and include the `X-Found-Cluster` header with the cluster’s UUID. You can get the cluster ID by clicking the `Copy cluster ID` link on your deployment’s main page. - -``` -server { - listen 443 ssl; - server_name elasticsearch.example.com; - - include /etc/nginx/tls.conf; - - location / { - proxy_pass https://.eu-west-1.aws.elastic-cloud.com/; - proxy_set_header X-Found-Cluster ; - } -} -``` - -This should work for all of your applications, not just {{es}}. To set it up for {{kib}}, for example, you can select `Copy cluster ID` next to {{kib}} on your deployment’s main page to get the correct UUID. - -::::{note} -Doing this for {{kib}} won't work with Cloud SSO. -:::: - - -To configure `tls.conf in this example, check out [https://ssl-config.mozilla.org/](https://ssl-config.mozilla.org/) for more fields. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-restoring-snapshots.md b/raw-migrated-files/cloud/cloud-heroku/ech-restoring-snapshots.md deleted file mode 100644 index f5c0967938..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-restoring-snapshots.md +++ /dev/null @@ -1,18 +0,0 @@ -# Work with snapshots [ech-restoring-snapshots] - -Snapshots provide a way to restore your Elasticsearch indices. They can be used to copy indices for testing, to recover from failures or accidental deletions, or to migrate data to other deployments. - -By default, Elasticsearch Add-On for Heroku takes a snapshot of all the indices in your Elasticsearch cluster every 30 minutes. You can set a different snapshot interval, if needed for your environment. You can also take snapshots on demand, without having to wait for the next interval. Taking a snapshot on demand does not affect the retention schedule for existing snapshots, it just adds an additional snapshot to the repository. This might be helpful if you are about to make a deployment change and you don’t have a current snapshot. - -Use Kibana to manage your snapshots. In Kibana, you can set up additional repositories where the snapshots are stored, other than the one currently managed by Elasticsearch Add-On for Heroku. You can view and delete snapshots, and configure a snapshot lifecycle management (SLM) policy to automate when snapshots are created and deleted. To learn more, check the [Snapshot and Restore](../../../deploy-manage/tools/snapshot-and-restore/create-snapshots.md) documentation. - -::::{important} -Snapshots back up only open indices. If you close an index, it is not included in snapshots and you will not be able to restore the data. -:::: - - -::::{note} -A snapshot taken using the default `found-snapshots` repository can only be restored to deployments in the same region. If you need to restore snapshots across regions, create the destination deployment, connect to the [custom repository](../../../deploy-manage/tools/snapshot-and-restore/elastic-cloud-hosted.md), and then [restore from a snapshot](../../../deploy-manage/tools/snapshot-and-restore/restore-snapshot.md). -:::: - - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-security.md b/raw-migrated-files/cloud/cloud-heroku/ech-security.md deleted file mode 100644 index 980b79ede3..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-security.md +++ /dev/null @@ -1,18 +0,0 @@ -# Securing your deployment [ech-security] - -The security of Elasticsearch Add-On for Heroku is described on the [{{ecloud}} security](https://www.elastic.co/cloud/security) page. In addition to the security provided by {{ecloud}}, you can take the following steps to secure your deployments: - -* Prevent unauthorized access with password protection and role-based access control: - - * Reset the [`elastic` user password](../../../deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). - * Use third-party authentication providers and services like [SAML](../../../deploy-manage/users-roles/cluster-or-deployment-auth/saml.md), [OpenID Connect](../../../deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md), or [Kerberos](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md) to provide dynamic [role mappings](../../../deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md) for role based or attribute based access control. - * Use {{kib}} Spaces and roles to [secure access to {{kib}}](../../../deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md). - * Authorize and authenticate service accounts for {{beats}} by [granting access using API keys](beats://reference/filebeat/beats-api-keys.md). - * Roles can provide full, or read only, access to your data and can be created in Kibana or directly in Elasticsearch. Check [defining roles](../../../deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for full details. - - -* Block unwanted traffic with [traffic filter](../../../deploy-manage/security/traffic-filtering.md). -* Secure your settings with the Elasticsearch [keystore](../../../deploy-manage/security/secure-settings.md). - -In addition, we also enable encryption at rest (EAR) by default. Elasticsearch Add-On for Heroku supports EAR for both the data stored in your clusters and the snapshots we take for backup, on all cloud platforms and across all regions. - diff --git a/raw-migrated-files/cloud/cloud-heroku/ech-snapshot-restore.md b/raw-migrated-files/cloud/cloud-heroku/ech-snapshot-restore.md deleted file mode 100644 index 242505fb63..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/ech-snapshot-restore.md +++ /dev/null @@ -1,23 +0,0 @@ -# Snapshot and restore [ech-snapshot-restore] - -Snapshots are an efficient way to ensure that your Elasticsearch indices can be recovered in the event of an accidental deletion, or to migrate data across deployments. - -The information here is specific to managing repositories and snapshots in Elasticsearch Add-On for Heroku. We also support the Elasticsearch snapshot and restore API to back up your data. For details, consult the [Snapshot and Restore documentation](../../../deploy-manage/tools/snapshot-and-restore.md). - -When you create a cluster in Elasticsearch Add-On for Heroku, a default repository called `found-snapshots` is automatically added to the cluster. This repository is specific to that cluster: the deployment ID is part of the repository’s `base_path`, i.e., `/snapshots/[cluster-id]`. - -::::{important} -Do not disable or delete the default `cloud-snapshot-policy` SLM policy, and do not change the default `found-snapshots` repository defined in that policy. These actions are not supported. - -The default policy and repository are used when creating a new deployment from a snapshot, when restoring a snapshot to a different deployment, and when taking automated snapshots in case of deployment changes. You can however customize the snapshot retention settings in that policy to adjust it to your needs. - -To use a custom snapshot repository, you can [register a new snapshot repository](../../../deploy-manage/tools/snapshot-and-restore/self-managed.md) and [create another SLM policy](../../../deploy-manage/tools/snapshot-and-restore/create-snapshots.md#create-slm-policy). - -:::: - - -To get started with snapshots, check out the following pages: - -* [Add your own custom repositories](../../../deploy-manage/tools/snapshot-and-restore/elastic-cloud-hosted.md) to snapshot to and restore from. -* To configure your cluster snapshot settings, see the [Snapshot and Restore documentation](../../../deploy-manage/tools/snapshot-and-restore.md). - diff --git a/raw-migrated-files/cloud/cloud-heroku/index.md b/raw-migrated-files/cloud/cloud-heroku/index.md deleted file mode 100644 index d0ba47baa2..0000000000 --- a/raw-migrated-files/cloud/cloud-heroku/index.md +++ /dev/null @@ -1,3 +0,0 @@ -# Elastic Cloud Heroku - -Migrated files from the Elastic Cloud Heroku book. \ No newline at end of file diff --git a/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index 97e39d38b2..b76cc28514 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -20,24 +20,6 @@ toc: - file: cloud/cloud-enterprise/ece-securing-clusters.md - file: cloud/cloud-enterprise/ece-securing-ece.md - file: cloud/cloud-enterprise/ece-upgrade.md - - file: cloud/cloud-heroku/index.md - children: - - file: cloud/cloud-heroku/ech-about.md - - file: cloud/cloud-heroku/ech-access-kibana.md - - file: cloud/cloud-heroku/ech-activity-page.md - - file: cloud/cloud-heroku/ech-add-user-settings.md - - file: cloud/cloud-heroku/ech-custom-repository.md - - file: cloud/cloud-heroku/ech-delete-deployment.md - - file: cloud/cloud-heroku/ech-editing-user-settings.md - - file: cloud/cloud-heroku/ech-enable-kibana2.md - - file: cloud/cloud-heroku/ech-getting-started.md - - file: cloud/cloud-heroku/ech-manage-apm-settings.md - - file: cloud/cloud-heroku/ech-manage-kibana-settings.md - - file: cloud/cloud-heroku/ech-planning.md - - file: cloud/cloud-heroku/ech-regional-deployment-aliases.md - - file: cloud/cloud-heroku/ech-restoring-snapshots.md - - file: cloud/cloud-heroku/ech-security.md - - file: cloud/cloud-heroku/ech-snapshot-restore.md - file: cloud/cloud/index.md children: - file: cloud/cloud/ec-faq-technical.md diff --git a/troubleshoot/index.md b/troubleshoot/index.md index 7c931ce4fc..c9bc51f67a 100644 --- a/troubleshoot/index.md +++ b/troubleshoot/index.md @@ -4,6 +4,7 @@ mapped_urls: - https://www.elastic.co/guide/en/starting-with-the-elasticsearch-platform-and-its-solutions/current/get-support-help.html - https://www.elastic.co/guide/en/starting-with-the-elasticsearch-platform-and-its-solutions/current/troubleshooting-and-faqs.html - https://www.elastic.co/guide/en/cloud/current/ec-get-help.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-get-help.html --- # Troubleshooting