You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -274,10 +274,10 @@ $$$azure-integration-billing-different-deployments$$$How do I get different Elas
274
274
: See [Integrated billing](#ec-azure-integration-billing-summary). To have different Elastic deployment/resources costs reported to different Azure subscriptions, they need to be in separate {{ecloud}} organizations. To create a separate {{ecloud}} organization from an Azure subscription, you will need to subscribe as a user who is not already part of an existing {{ecloud}} organization.
275
275
276
276
$$$azure-integration-billing-elastic-costs$$$Why can’t I see Elastic resources costs in Azure Cost Explorer?
277
-
: The costs associated with Elastic resources (deployments) are reported under unassigned in the Azure Portal. Refer to [Understand your Azure external services charges](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/understand-azure-marketplace-charges) in the Microsoft Documentation to understand Elastic resources/deployments costs. For granular Elastic resources costs, refer to [Monitor and analyze your acccount usage](../../cloud-organization/billing/monitor-analyze-usage.md).
277
+
: The costs associated with Elastic resources (deployments) are reported under unassigned in the Azure Portal. Refer to [Understand your Azure external services charges](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/understand-azure-marketplace-charges) in the Microsoft Documentation to understand Elastic resources/deployments costs. For granular Elastic resources costs, refer to [Monitor and analyze your account usage](../../cloud-organization/billing/monitor-analyze-usage.md).
278
278
279
279
$$$azure-integration-billing-deployments$$$Why don’t I see my individual Elastic resources (deployments) in the Azure Marketplace Invoice?
280
-
: The way Azure Marketplace Billing Integration works today, the costs for Elastic resources (deployments) are reported for an {{ecloud}} organization as a single line item, reported against the Marketplace SaaS ID. This includes the Elastic deployments created using the Azure Portal, API, SDK, or CLI, and also the Elastic deployments created directly from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) in the respective {{ecloud}} organization. For granular Elastic resources costs refer to [Monitor and analyze your acccount usage](../../cloud-organization/billing/monitor-analyze-usage.md). As well, for more detail refer to [Integrated billing](#ec-azure-integration-billing-summary).
280
+
: The way Azure Marketplace Billing Integration works today, the costs for Elastic resources (deployments) are reported for an {{ecloud}} organization as a single line item, reported against the Marketplace SaaS ID. This includes the Elastic deployments created using the Azure Portal, API, SDK, or CLI, and also the Elastic deployments created directly from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) in the respective {{ecloud}} organization. For granular Elastic resources costs refer to [Monitor and analyze your account usage](../../cloud-organization/billing/monitor-analyze-usage.md). As well, for more detail refer to [Integrated billing](#ec-azure-integration-billing-summary).
:alt: Example billing report in the {{ecloud}} console
@@ -289,7 +289,7 @@ $$$azure-integration-billing-instance-values$$$Why can’t I find Instance ID an
289
289
290
290
For instance: Elastic Organization `Org1` is associated with a Marketplace SaaS (Microsoft.SaaS) asset `AzureElastic_GUID_NAME`. The Elastic resources (`Microsoft.Elastic`) `E1`, `E2`, and `E3` within `Org1` are all mapped to `AzureElastic_GUID_NAME`.
291
291
292
-
`Microsoft.SaaS` (Instance name) asset is shown in the Azure Marketplace invoice and represents costs related to an {{ecloud}} organization and not individual Elastic resources (deployments). To see the cost breakdown for individual Elastic resources (deployments), refer to [Monitor and analyze your acccount usage](../../cloud-organization/billing/monitor-analyze-usage.md).
292
+
`Microsoft.SaaS` (Instance name) asset is shown in the Azure Marketplace invoice and represents costs related to an {{ecloud}} organization and not individual Elastic resources (deployments). To see the cost breakdown for individual Elastic resources (deployments), refer to [Monitor and analyze your account usage](../../cloud-organization/billing/monitor-analyze-usage.md).
|**Behavioral analytics**| ❌ (deprecated in 9.0) | ❌ | Not available in Serverless |
88
88
|[**Clone index API**](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-clone)| ✅ |**Planned**| Anticipated in a future release |
89
-
|[**Bulk indexing**](/deploy-manage/production-guidance/optimize-performance/indexing-speed.md#_use_bulk_requests)| ✅ | ✅ | The maximum bulk request response time in {{serverless-short}} is 200ms |
89
+
|[**Bulk indexing**](/deploy-manage/production-guidance/optimize-performance/indexing-speed.md#_use_bulk_requests)| ✅ | ✅ | The baseline write latency in {{serverless-short}} is 200ms[^1^](#footnote-1)|
90
90
|[**Cross-cluster replication**](/deploy-manage/tools/cross-cluster-replication.md)| ✅ |**Planned**| Anticipated in a future release |
91
91
|[**Cross-cluster search**](/solutions/search/cross-cluster-search.md)| ✅ |**Planned**| Anticipated in a future release |
92
92
|**Data lifecycle management**| - [ILM](/manage-data/lifecycle/index-lifecycle-management.md) <br>- [Data stream lifecycle](/manage-data/lifecycle/data-stream.md)|[Data stream lifecycle](/manage-data/lifecycle/data-stream.md) only | - No data tiers in Serverless <br>- Optimized for common lifecycle management needs |
@@ -103,6 +103,8 @@ This table compares Elasticsearch capabilities between {{ech}} deployments and S
103
103
|[**Watcher**](/explore-analyze/alerts-cases/watcher.md)| ✅ | ❌ | Use **Kibana Alerts** instead, which provides rich integrations across use cases |
104
104
|**Web crawler**| ❌ (Managed Elastic Crawler discontinued with Enterprise Search in 9.0) | Self-managed only | Use [**self-managed crawler**](https://github.com/elastic/crawler)|
105
105
106
+
^1^ $$$footnote-1$$$ In {{serverless-short}}, Elastic ensures data durability by storing indexed data in an [object store](https://www.elastic.co/blog/elastic-serverless-architecture) rather than local replicas. Writes are batched over a 200ms window to ensure durability while optimizing performance and cost, which means that single-document indexing can appear slower than in {{ech}}. However, this design makes {{serverless-short}} more scalable and resilient to high indexing loads without relying on in-cluster replication for fault tolerance. Because of a higher baseline write latency, {{serverless-short}} indexing can be scaled by increasing concurrent indexing clients.
107
+
106
108
### Observability
107
109
108
110
This table compares Observability capabilities between {{ech}} deployments and Observability Complete Serverless projects. For more information on Observability Logs Essentials Serverless projects, refer to [Observability feature tiers](../../../solutions/observability/observability-serverless-feature-tiers.md).
@@ -117,7 +119,9 @@ This table compares Observability capabilities between {{ech}} deployments and O
4. In the `.env` file, specify a password for the `ELASTIC_PASSWORD` and `KIBANA_PASSWORD` variables.
30
30
@@ -104,4 +104,4 @@ docker-compose down -v
104
104
105
105
## Next steps [_next_steps_6]
106
106
107
-
You now have a test {{es}} environment set up. Before you start serious development or go into production with {{es}}, review the [requirements and recommendations](/deploy-manage/deploy/self-managed/install-elasticsearch-docker-prod.md) to apply when running {{es}} in Docker in production.
107
+
You now have a test {{es}} environment set up. Before you start serious development or go into production with {{es}}, review the [requirements and recommendations](/deploy-manage/deploy/self-managed/install-elasticsearch-docker-prod.md) to apply when running {{es}} in Docker in production.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,8 @@ products:
19
19
AutoOps diagnoses issues in {{es}} by analyzing hundreds of metrics, providing root-cause analysis and accurate resolution paths. With AutoOps, customers can prevent and resolve issues, cut down administration time, and optimize resource utilization.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/cc-cloud-connect-autoops-troubleshooting.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ $$$next-steps$$$**After running the installation command, I can't move on to the
38
38
: If an error appears on the screen, follow the suggestion in the error message and try to run the command again. If the issue is not resolved, explore [additional resources](/troubleshoot/index.md#troubleshoot-additional-resources) or [contact us](/troubleshoot/index.md#contact-us).
39
39
40
40
$$$firewall$$$**My organization's firewall may be preventing {{agent}} from collecting and sending metrics.**
41
-
: If yoususpect that a corporate firewall is hindering {{agent}}, complete the following steps to test each component of the connection and implement an appropriate solution.
41
+
: If you're having issues with connecting your self-managed cluster to AutoOps and you suspect that a firewall may be the reason, complete the following steps to test each component of the connection and implement an appropriate solution.
42
42
43
43
:::{tip}
44
44
Run the following tests within the context of your execution environment. That is, if your chosen installation method is Kubernetes, run the commands from within the pod; for Docker, run the commands from within the container, and so on.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -102,6 +102,10 @@ Select one of the following methods to install {{agent}}:
102
102
* **Windows**
103
103
-->
104
104
105
+
:::{note}
106
+
macOS is not a supported platform for installing {{agent}} to connect to AutoOps in a self-managed production environment. However, you can use macOS to [connect your local development cluster to AutoOps](/deploy-manage/monitor/autoops/cc-connect-local-dev-to-autoops.md).
107
+
:::
108
+
105
109
:::{important}
106
110
Using AutoOps for your ECE, ECK, and self-managed clusters requires a new, dedicated {{agent}}. You must install an agent even if you already have an existing one for other purposes.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-deployment-view.md
+25-17Lines changed: 25 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,43 +16,51 @@ products:
16
16
17
17
# Deployment or Cluster view in AutoOps [ec-autoops-deployment-view]
18
18
19
-
The **Deployment** view (for {{ECH}} deployments) or **Cluster** view (for ECE, ECK, and self-managed clusters), is the event control panel that allows you to see which issues are affecting the {{es}} cluster and get a list of action items to address them.
19
+
The **Deployment** view (for {{ECH}} deployments) or **Cluster** view (for ECE, ECK, and self-managed clusters), is the event control panel that gives you an overview of the events, resource usage, and performance of your deployments or clusters.
20
20
21
-
## Events over time [ec-autoops-events-over-time]
21
+
To get to this view, go to AutoOps in your deployment or cluster and select **Deployment** or **Cluster** from the side navigation.
22
22
23
-
The **Events Over Time** panel lists all the recent events the {{es}} cluster has triggered, ordered by criticality. It also gives a color-coded heat map to help understand when and how often a particular event happened. Click on any mosaic to get details about a particular event, for example the specific node/index/shard affected, event time and duration, and a detailed description of the actions you can take to mitigate that event.
23
+
You can use the **Deployment** or **Cluster** dropdown at the top of the screen to select which deployment or cluster you want to monitor.
24
24
25
-
Refer to [AutoOps events](ec-autoops-events.md) for more details.
25
+
## Panels in the Deployment or Cluster view
26
26
27
+
The **Deployment** or **Cluster** view shows the following panels.
27
28
28
-
##Open events [ec-autoops-open-events]
29
+
### Events over time [ec-autoops-events-over-time]
29
30
30
-
The **Open Events** panel lists open events sorted by severity and time. When the conditions that triggered the event no longer exist, the event is automatically set to close and appear in the **Events History** panel. Closing an event does not necessarily indicate that the customer resolved the issue, but rather that AutoOps no longer detects it.
31
+
The **Events Over Time** panel lists all the recent events the {{es}} cluster has triggered, ordered by criticality. It also displays a color-coded heat map to help understand when and how often a particular event happened. Click on any mosaic to get details about a particular event, such as the specific node, index, or shard affected, event time and duration, and a detailed description of the actions you can take to mitigate that event.
31
32
33
+
Refer to [AutoOps events](ec-autoops-events.md) for more details.
32
34
33
-
##Events History [ec-events-history]
35
+
### Open Events [ec-autoops-open-events]
34
36
35
-
The **Events History** panel lists events that happened at some point and that have been triggered, but some conditions changed and are no longer active. For example, when your cluster experiences a peak in search rate, that might trigger a "Too many tasks on queue" event. Now, your cluster is more relaxed in terms of search rate, so this event is no longer an issue, but it was recorded for historical reasons. Events history is also sorted by severity first and then by time.
37
+
The **Open Events** panel lists open events sorted by severity and time. When the conditions that triggered the event no longer exist, the event is automatically set to close and appear in the **Events History** panel. Closing an event does not necessarily indicate that the customer resolved the issue, but rather that AutoOps no longer detects it.
36
38
39
+
### Events History [ec-events-history]
37
40
38
-
## Resources [ec-deployment-resources]
41
+
The **Events History** panel lists events that were triggered in the past but are no longer active because of changed conditions.
42
+
43
+
Let's say your cluster experienced a peak in search rate, triggering a "Too many tasks on queue" event. Now, your cluster is more relaxed in terms of search rate, so this event is no longer an issue, but it was recorded for historical reasons. Like Open Events, Events History is also sorted first by severity and then by time.
44
+
45
+
### Resources [ec-deployment-resources]
39
46
40
47
The **Resources** panel provides a quick overview of {{es}} cluster resource usage. The resources are presented based on their respective data tiers and include JVM memory usage, CPU usage, and storage usage over time. You can view essential cluster information such as the {{es}} version, total number of nodes, total number of shards, and total volume of used storage.
The **Performance** panel shows the following key performance metrics aggregated at both the cluster level and the selected tier levels:
54
57
55
58
***Search rate**: The number of search requests executed per second across all shards in the deployment or cluster, as well as within the selected data tiers.
56
59
***Search latency**: The average latency of search operations across all shards in the deployment or cluster, and within the selected data tiers.
57
60
***Indexing rate**: The number of documents indexed per second across all shards in the deployment or cluster, as well as within the selected data tiers.
58
61
***Indexing latency**: The average latency of indexing operations across all shards in the deployment or cluster, and within the selected data tiers.
0 commit comments