- Introducing Elasticsearch Service
- Adding data to Elasticsearch
- Migrating data
- Ingesting data from your application
- Ingest data with Node.js on Elasticsearch Service
- Ingest data with Python on Elasticsearch Service
- Ingest data from Beats to Elasticsearch Service with Logstash as a proxy
- Ingest data from a relational database into Elasticsearch Service
- Ingest logs from a Python application using Filebeat
- Ingest logs from a Node.js web application using Filebeat
- Configure Beats and Logstash with Cloud ID
- Best practices for managing your data
- Configure index management
- Enable cross-cluster search and cross-cluster replication
- Access other deployments of the same Elasticsearch Service organization
- Access deployments of another Elasticsearch Service organization
- Access deployments of an Elastic Cloud Enterprise environment
- Access clusters of a self-managed environment
- Enabling CCS/R between Elasticsearch Service and ECK
- Edit or remove a trusted environment
- Migrate the cross-cluster search deployment template
- Manage data from the command line
- Preparing a deployment for production
- Securing your deployment
- Monitoring your deployment
- Monitor with AutoOps
- Configure Stack monitoring alerts
- Access performance metrics
- Keep track of deployment activity
- Diagnose and resolve issues
- Diagnose unavailable nodes
- Why are my shards unavailable?
- Why is performance degrading over time?
- Is my cluster really highly available?
- How does high memory pressure affect performance?
- Why are my cluster response times suddenly so much worse?
- How do I resolve deployment health warnings?
- How do I resolve node bootlooping?
- Why did my node move to a different host?
- Snapshot and restore
- Managing your organization
- Your account and billing
- Billing Dimensions
- Billing models
- Using Elastic Consumption Units for billing
- Edit user account settings
- Monitor and analyze your account usage
- Check your subscription overview
- Add your billing details
- Choose a subscription level
- Check your billing history
- Update billing and operational contacts
- Stop charges for a deployment
- Billing FAQ
- Elasticsearch Service hardware
- Elasticsearch Service GCP instance configurations
- Elasticsearch Service GCP default provider instance configurations
- Elasticsearch Service AWS instance configurations
- Elasticsearch Service AWS default provider instance configurations
- Elasticsearch Service Azure instance configurations
- Elasticsearch Service Azure default provider instance configurations
- Change hardware for a specific resource
- Elasticsearch Service regions
- About Elasticsearch Service
- RESTful API
- Release notes
- Enhancements and bug fixes - December 2024
- Enhancements and bug fixes - November 2024
- Enhancements and bug fixes - Late October 2024
- Enhancements and bug fixes - Early October 2024
- Enhancements and bug fixes - September 2024
- Enhancements and bug fixes - Late August 2024
- Enhancements and bug fixes - Early August 2024
- Enhancements and bug fixes - July 2024
- Enhancements and bug fixes - Late June 2024
- Enhancements and bug fixes - Early June 2024
- Enhancements and bug fixes - Early May 2024
- Bring your own key, and more
- AWS region EU Central 2 (Zurich) now available
- GCP region Middle East West 1 (Tel Aviv) now available
- Enhancements and bug fixes - March 2024
- Enhancements and bug fixes - January 2024
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- AWS region EU North 1 (Stockholm) now available
- GCP regions Asia Southeast 2 (Indonesia) and Europe West 9 (Paris)
- Enhancements and bug fixes
- Enhancements and bug fixes
- Bug fixes
- Enhancements and bug fixes
- Role-based access control, and more
- Newly released deployment templates for Integrations Server, Master, and Coordinating
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Enhancements and bug fixes
- Cross environment search and replication, and more
- Enhancements and bug fixes
- Enhancements and bug fixes
- Azure region Canada Central (Toronto) now available
- Azure region Brazil South (São Paulo) now available
- Azure region South Africa North (Johannesburg) now available
- Azure region Central India (Pune) now available
- Enhancements and bug fixes
- Azure new virtual machine types available
- Billing Costs Analysis API, and more
- Organization and billing API updates, and more
- Integrations Server, and more
- Trust across organizations, and more
- Organizations, and more
- Elastic Consumption Units, and more
- AWS region Africa (Cape Town) available
- AWS region Europe (Milan) available
- AWS region Middle East (Bahrain) available
- Enhancements and bug fixes
- Enhancements and bug fixes
- GCP Private Link, and more
- Enhancements and bug fixes
- GCP region Asia Northeast 3 (Seoul) available
- Enhancements and bug fixes
- Enhancements and bug fixes
- Native Azure integration, and more
- Frozen data tier and more
- Enhancements and bug fixes
- Azure region Southcentral US (Texas) available
- Azure region East US (Virginia) available
- Custom endpoint aliases, and more
- Autoscaling, and more
- Cross-region and cross-provider support, warm and cold data tiers, and more
- Better feature usage tracking, new cost and usage analysis page, and more
- New features, enhancements, and bug fixes
- AWS region Asia Pacific (Hong Kong)
- Enterprise subscription self service, log in with Microsoft, bug fixes, and more
- SSO for Enterprise Search, support for more settings
- Azure region Australia East (New South Wales)
- New logging features, better GCP marketplace self service
- Azure region US Central (Iowa)
- AWS region Asia Pacific (Mumbai)
- Elastic solutions and Microsoft Azure Marketplace integration
- AWS region Pacific (Seoul)
- AWS region EU West 3 (Paris)
- Traffic management and improved network security
- AWS region Canada (Central)
- Enterprise Search
- New security setting, in-place configuration changes, new hardware support, and signup with Google
- Azure region France Central (Paris)
- Regions AWS US East 2 (Ohio) and Azure North Europe (Ireland)
- Our Elasticsearch Service API is generally available
- GCP regions Asia East 1 (Taiwan), Europe North 1 (Finland), and Europe West 4 (Netherlands)
- Azure region UK South (London)
- GCP region US East 1 (South Carolina)
- GCP regions Asia Southeast 1 (Singapore) and South America East 1 (Sao Paulo)
- Snapshot lifecycle management, index lifecycle management migration, and more
- Azure region Japan East (Tokyo)
- App Search
- GCP region Asia Pacific South 1 (Mumbai)
- GCP region North America Northeast 1 (Montreal)
- New Elastic Cloud home page and other improvements
- Azure regions US West 2 (Washington) and Southeast Asia (Singapore)
- GCP regions US East 4 (N. Virginia) and Europe West 2 (London)
- Better plugin and bundle support, improved pricing calculator, bug fixes, and more
- GCP region Asia Pacific Southeast 1 (Sydney)
- Elasticsearch Service on Microsoft Azure
- Cross-cluster search, OIDC and Kerberos authentication
- AWS region EU (London)
- GCP region Asia Pacific Northeast 1 (Tokyo)
- Usability improvements and Kibana bug fix
- GCS support and private subscription
- Elastic Stack 6.8 and 7.1
- ILM and hot-warm architecture
- Elasticsearch keystore and more
- Trial capacity and more
- APM Servers and more
- Snapshot retention period and more
- Improvements and snapshot intervals
- SAML and multi-factor authentication
- Next generation of Elasticsearch Service
- Branding update
- Minor Console updates
- New Cloud Console and bug fixes
- What’s new with the Elastic Stack
Enable logging and monitoring
editEnable logging and monitoring
editThe deployment logging and monitoring feature lets you monitor your deployment in Kibana by shipping logs and metrics to a monitoring deployment. You can:
- View your deployment’s health and performance in real time and analyze past cluster, index, and node metrics.
- View your deployment’s logs to debug issues, discover slow queries, surface deprecations, and analyze access to your deployment.
Monitoring consists of two components:
- A monitoring and logging agent that is installed on each node in your deployment. The agents collect and index metrics to Elasticsearch, either on the same deployment or by sending logs and metrics to an external monitoring deployment. Elasticsearch Service manages the installation and configuration of the monitoring agent for you, and you should not modify any of the settings.
- The stack monitoring application in Kibana that visualizes the monitoring metrics through a dashboard and the logs application that allows you to search and analyze deployment logs.
The steps in this section cover only the enablement of the monitoring and logging features in Elasticsearch Service. For more information on how to use the monitoring features, refer to Monitor a cluster.
Before you begin
editSome limitations apply when you use monitoring on Elasticsearch Service. To learn more, check the monitoring restrictions and limitations.
Monitoring for production use
editFor production use, you should send your deployment logs and metrics to a dedicated monitoring deployment. Monitoring indexes logs and metrics into Elasticsearch and these indexes consume storage, memory, and CPU cycles like any other index. By using a separate monitoring deployment, you avoid affecting your other production deployments and can view the logs and metrics even when a production deployment is unavailable.
How many monitoring deployments you use depends on your requirements:
- You can ship logs and metrics for many deployments to a single monitoring deployment, if your business requirements permit it.
- Although monitoring will work with a deployment running a single node, you need a minimum of three monitoring nodes to make monitoring highly available.
-
You might need to create dedicated monitoring deployments for isolation purposes in some cases. For example:
- If you have many deployments and some of them are much larger than others, creating separate monitoring deployments prevents a large deployment from potentially affecting monitoring performance for smaller deployments.
- If you need to silo Elasticsearch data for different business departments. Deployments that have been configured to ship logs and metrics to a target monitoring deployment have access to indexing data and can manage monitoring index templates, which is addressed by creating separate monitoring deployments.
Logs and metrics that get sent to a dedicated monitoring Elasticsearch deployment may not be cleaned up automatically and might require some additional steps to remove excess data periodically.
Retention of monitoring daily indices
editStack versions 8.0 and above
editWhen you enable monitoring in Elasticsearch Service, your monitoring indices are retained
for a certain period by default. After the retention period has passed,
the monitoring indices are deleted automatically. The retention period
is configured in the .monitoring-8-ilm-policy
index lifecycle policy.
To view or edit the policy open Kibana
Stack management > Data > Index Lifecycle Policies.
Sending monitoring data to itself (self monitoring)
editWhen you enable self-monitoring in Elasticsearch Service, your monitoring indices are retained for a certain period by default. After the retention period has passed, the monitoring indices are deleted automatically. Monitoring data is retained for three days by default or as specified by the xpack.monitoring.history.duration
user setting.
To retain monitoring indices as is without deleting them automatically, you must disable the cleaner service by adding a disabled local exporter in your cluster settings.
For example
PUT /_cluster/settings { "persistent": { "xpack.monitoring.exporters.__no-default-local__": { "type": "local", "enabled": false } } }
Sending monitoring data to a dedicated monitoring deployment
editWhen monitoring for production use, where you configure your deployments to send monitoring data to a dedicated monitoring deployment for indexing, this retention period does not apply. Monitoring indices on a dedicated monitoring deployment are retained until you remove them. There are three options open to you:
- To enable the automatic deletion of monitoring indices from dedicated monitoring deployments, enable monitoring on your dedicated monitoring deployment in Elasticsearch Service to send monitoring data to itself. When an Elasticsearch deployment sends monitoring data to itself, all monitoring indices are deleted automatically after the retention period, regardless of the origin of the monitoring data.
-
Alternatively, you can enable the cleaner service on the monitoring deployment by creating a local exporter. You can define the retention period at the same time.
For example
PUT _cluster/settings { "persistent": { "xpack" : { "monitoring" : { "exporters" : { "found-user-defined" : { "type" : "local", "enabled" : "true" } }, "history" : { "duration" : "24h" } } } } }
- To retain monitoring indices on a dedicated monitoring deployment as is without deleting them automatically, no additional steps are required other than making sure that you do not enable the monitoring deployment to send monitoring data to itself. You should also monitor the deployment for disk space usage and upgrade your deployment periodically, if necessary.
Retention of logging indices
editAn ILM policy is pre-configured to manage log retention. The policy can be adjusted according to your requirements.
Index management
editWhen sending monitoring data to a deployment, you can configure Index Lifecycle Management (ILM) to manage retention of your monitoring and logging indices. When sending logs to a deployment, an ILM policy is pre-configured to manage log retention and the policy can be customized to your needs.
Enable logging and monitoring
editElasticsearch Service manages the installation and configuration of the monitoring agent for you. When you enable monitoring on a deployment, you are configuring where the monitoring agent for your current deployment should send its logs and metrics.
To enable monitoring on your deployment:
- Log in to the Elasticsearch Service Console.
-
Find your deployment on the home page in the Elasticsearch Service card and select Manage to access it directly. Or, select Hosted deployments to go to the deployments page to view all of your deployments.
On the deployments page you can 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.
- From your deployment menu, go to the Logs and metrics page.
- Select Enable.
-
Choose where to send your logs and metrics. Select Save.
If a deployment is not listed, make sure that it is running a compatible version. The monitoring deployment and production deployment must be on the same major version, cloud provider, and region.
Remember to send logs and metrics for production deployments to a dedicated monitoring deployment, so that your production deployments are not impacted by the overhead of indexing and storing monitoring data. A dedicated monitoring deployment also gives you more control over the retention period for monitoring data.
Enabling logs and monitoring may trigger a plan change on your deployment. You can monitor the plan change progress from the deployment’s Activity page.
Enabling logs and monitoring requires some extra resource on a deployment. For production systems, we recommend sizing deployments with logs and monitoring enabled to at least 4 GB of RAM.
Access the monitoring application in Kibana
editWith monitoring enabled for your deployment, you can access the logs and stack monitoring through Kibana.
- Log in to the Elasticsearch Service Console.
-
Find your deployment on the home page in the Elasticsearch Service card and select Manage to access it directly. Or, select Hosted deployments to go to the deployments page to view all of your deployments.
On the deployments page you can 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.
- From your deployment menu, go to the Logs and Metrics page.
- Select the corresponding View button to check the logs or metrics data.
Alternatively, you can access logs and metrics directly on the Kibana Logs and Stack Monitoring pages in the target monitoring deployment. You can also create an elastic-cloud-logs-*
data view (formerly index pattern) to view your deployment’s logs in the Kibana Discover tab. Several fields are available for you to view logs based on key details, such as the source deployment:
Field | Description | Example value |
---|---|---|
|
The ID of the deployment that generated the log |
|
|
The name of the deployment that generated the log |
|
|
The availability zone in which the instance that generated the log is deployed |
|
|
The ID of the instance that generated the log |
|
|
The type of instance that generated the log |
|
|
The version of the stack resource that generated the log |
|
Logging features
editWhen shipping logs to a monitoring deployment there are more logging features available to you. These features include:
For Elasticsearch:
edit- Audit logging - logs security-related events on your deployment
- Slow query and index logging - helps find and debug slow queries and indexing
- Verbose logging - helps debug stack issues by increasing component logs
After you’ve enabled log delivery on your deployment, you can add the Elasticsearch user settings to enable these features.
For Kibana:
edit- Audit logging - logs security-related events on your deployment
After you’ve enabled log delivery on your deployment, you can add the Kibana user settings to enable this feature.
Other components
editEnabling log collection also supports collecting and indexing the following types of logs from other components in your deployments:
Enterprise Search
- connectors.log*
- crawler.log*
- filebeat*
- app-server.log*
- system.log*
- worker.log*
- kibana.log*
App Search
- app-search*.log
APM
- apm*.log*
Fleet and Elastic Agent
- fleet-server-json.log-*
- elastic-agent-json.log-*
The ˆ*ˆ indicates that we also index the archived files of each type of log.
Check the respective product documentation for more information about the logging capabilities of each product.
Metrics features
editWith logging and monitoring enabled for a deployment, metrics are collected for Elasticsearch, Kibana, Enterprise Search, and APM with Fleet Server.
Enabling Elasticsearch/Kibana audit logs on your deployment
editAudit logs are useful for tracking security events on your Elasticsearch and/or Kibana clusters. To enable Elasticsearch audit logs on your deployment:
- Log in to the Elasticsearch Service Console.
-
Find your deployment on the home page in the Elasticsearch Service card and select Manage to access it directly. Or, select Hosted deployments to go to the deployments page to view all of your deployments.
On the deployments page you can 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.
- From your deployment menu, go to the Edit page.
- To enable audit logs in Elasticsearch, 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 instead.
- To enable audit logs in Kibana, 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.
-
Add
xpack.security.audit.enabled: true
to the user settings. - Select Save changes.
A plan change will run on your deployment. When it finishes, audit logs will be delivered to your monitoring deployment.
Restrictions and limitations
edit- To avoid compatibility issues, ensure your monitoring cluster and production cluster run on the same Elastic Stack version. Monitoring clusters that use 8.x do work with production clusters that use the latest release of 7.x, but this setup should only occur when upgrading clusters to the same version.
- Monitoring across regions is not supported. If you need to move your existing monitoring to the same region, you can do a reindex or create a new deployment and select the snapshot from the old deployment.
- The logs shipped to a monitoring cluster use an ILM managed data stream (elastic-cloud-logs-<version>). If you need to delete indices due to space, do not delete the current is_write_enabled: true index.
- When sending metrics to a dedicated monitoring deployment, the graph for IO Operations Rate(/s) is blank. This is due to the fact that this graph actually contains metrics from of all of the virtualized resources from the provider.
On this page
- Before you begin
- Monitoring for production use
- Retention of monitoring daily indices
- Stack versions 8.0 and above
- Sending monitoring data to itself (self monitoring)
- Sending monitoring data to a dedicated monitoring deployment
- Retention of logging indices
- Index management
- Enable logging and monitoring
- Access the monitoring application in Kibana
- Logging features
- For Elasticsearch:
- For Kibana:
- Other components
- Metrics features
- Enabling Elasticsearch/Kibana audit logs on your deployment
- Restrictions and limitations