incorporated feedback

_monitoring-plugins/ad/api.md

@@ -24,7 +24,7 @@ Introduced 1.0
 
 Creates an anomaly detector.
 
-This command creates a single-flow detector named `test-detector` that finds anomalies based on the sum of the `value` field:
+This command creates a single-entity detector named `test-detector` that finds anomalies based on the sum of the `value` field:
 
 #### Request
 
@@ -544,8 +544,7 @@ GET _plugins/_anomaly_detection/detectors/<detectorId>?job=true
 }
 ```
 
-Use `task=true` to get historical analysis task information.
+Use `task=true` to get information for both real-time and historical analysis task information.
-You can set both `job=true` and `task=true` to get information for both real-time and historical analysis tasks.
 
 #### Request
 
@@ -1019,7 +1018,7 @@ Introduced 1.0
 
 Passes a date range to the anomaly detector to return any anomalies within that date range.
 
-To preview a single-flow detector:
+To preview a single-entity detector:
 
 #### Request
 
@@ -1165,7 +1164,7 @@ If you specify a category field, each result is associated with an entity:
 #### Request
 
 ```json
-POST _plugins/_anomaly_detection/detectors/<detectorId>/_preview
+POST _plugins/_anomaly_detection/detectors/_preview
 {
   "period_start": 1633048868000,
   "period_end": 1633394468000,
@@ -1662,7 +1661,7 @@ Introduced 1.1
 
 Searches detector tasks.
 
-To search for the latest detector task for a high cardinality detector:
+To search for the latest detector level historical analysis task for a high cardinality detector
 
 #### Request
 
@@ -1825,7 +1824,7 @@ POST _plugins/_anomaly_detection/detectors/tasks/_search
 }
 ```
 
-To search for the latest entity-level task for a high cardinality detector:
+To search for the latest entity-level tasks for the historical analysis of a high cardinality detector:
 
 #### Request
 
@@ -1865,7 +1864,12 @@ POST _plugins/_anomaly_detection/detectors/tasks/_search
 }
 ```
 
-To search for all entity-level batch task stats:
+To search and aggregate states for all entity-level historical tasks:
+
+The `parent_task_id` is the same as the task ID that you can get with the profile detector API:
+`GET _plugins/_anomaly_detection/detectors/<detector_ID>/_profile/ad_task`.
+{: .note }
+
 
 #### Request
 
@@ -1994,7 +1998,7 @@ POST _plugins/_anomaly_detection/detectors/results/_search
 }
 ```
 
-Because real-time analysis doesn't have a batch task, the task ID in the anomaly result is null.
+Real-time detection doesn't persist the task ID in the anomaly result, so the task ID will be null.
 
 #### Sample response
 
@@ -2309,6 +2313,11 @@ To get specific stats for a node:
 
 ```json
 GET _plugins/_anomaly_detection/<nodeId>/stats/<stat>
+```
+
+For example:
+
+```json
 GET _plugins/_anomaly_detection/<nodeId>/stats/ad_execute_request_count
 ```
 
@@ -2330,6 +2339,11 @@ To get a specific type of stats:
 
 ```json
 GET _plugins/_anomaly_detection/stats/<stat>
+```
+
+For example:
+
+```json
 GET _plugins/_anomaly_detection/stats/ad_executing_batch_task_count
 ```
 
@@ -2687,7 +2701,7 @@ Getting the total count of entities is an expensive operation for real-time anal
 
 The `profile` operation also provides information about each entity, such as the entity’s `last_sample_timestamp` and `last_active_timestamp`. `last_sample_timestamp` shows the last document in the input data source index containing the entity, while `last_active_timestamp` shows the timestamp when the entity’s model was last seen in the model cache.
 
-If there are no anomaly results for an entity, either the entity doesn't have any sample data or its model is removed from the model cache.
+If there are no anomaly results for an entity, either the entity doesn't have any sample data or resources such as memory and disk IO are constrained relative to the number of entities.
 
 #### Request
 

_monitoring-plugins/ad/index.md

@@ -153,7 +153,7 @@ If you stop or delete a detector, make sure to delete any monitors associated wi
 To see all the configuration settings for a detector, choose the **Detector configuration** tab.
 
 1. To make any changes to the detector configuration, or fine tune the time interval to minimize any false positives, go to the **Detector configuration** section and choose **Edit**.
-- You need to stop real-time or historical analysis to change its configuration. Confirm that you want to stop the detector and proceed.
+- You need to stop real-time and historical analysis to change its configuration. Confirm that you want to stop the detector and proceed.
 1. To enable or disable features, in the **Features** section, choose **Edit** and adjust the feature settings as needed. After you make your changes, choose **Save and start detector**.
 
 ### Step 8: Manage your detectors

_monitoring-plugins/ad/settings.md

@@ -29,7 +29,6 @@ Setting | Default | Description
 `plugins.anomaly_detection.max_multi_entity_anomaly_detectors` | 10 | The maximum number of high cardinality detectors (with category field) in a cluster.
 `plugins.anomaly_detection.max_anomaly_features` | 5 | The maximum number of features for a detector.
 `plugins.anomaly_detection.ad_result_history_rollover_period` | 12h | How often the rollover condition is checked. If `true`, the anomaly detection plugin rolls over the result index to a new index.
-`plugins.anomaly_detection.ad_result_history_max_docs` | 250,000,000 | The maximum number of documents in one result index. The anomaly detection plugin only counts refreshed documents in the primary shards.
 `plugins.anomaly_detection.ad_result_history_max_docs_per_shard` | 1,350,000,000 | The maximum number of documents in a single shard of the result index. The anomaly detection plugin only counts the refreshed documents in the primary shards.
 `plugins.anomaly_detection.max_entities_per_query` | 1,000,000 | The maximum unique values per detection interval for high cardinality detectors. By default, if the category field(s) have more than the configured unique values in a detector interval, the anomaly detection plugin orders them by the natural ordering of categorical values (for example, entity `ab` comes before `bc`) and then selects the top values.
 `plugins.anomaly_detection.max_entities_for_preview` | 5 | The maximum unique category field values displayed with the preview operation for high cardinality detectors. By default, if the category field(s) have more than the configured unique values in a detector interval, the anomaly detection plugin orders them by the natural ordering of categorical values (for example, entity `ab` comes before `bc`) and then selects the top values.
@@ -40,7 +39,7 @@ Setting | Default | Description
 `plugins.anomaly_detection.batch_task_piece_size` | 1,000 | The date range for a historical task is split into smaller pieces and the anomaly detection plugin runs the task piece by piece. Each piece contains 1,000 detection intervals by default. For example, if detector interval is 1 minute and one piece is 1,000 minutes, the feature data is queried every 1,000 minutes. You can change this setting from 1 to 10,000.
 `plugins.anomaly_detection.batch_task_piece_interval_seconds` | 5 | Add a time interval between two pieces of the same historical analysis task. This interval prevents the task from consuming too much of the available resources and starving other operations like search and bulk index. You can change this setting from 1 to 600 seconds.
 `plugins.anomaly_detection.max_top_entities_for_historical_analysis` | 1,000 | The maximum number of top entities that you run for a high cardinality detector historical analysis. The range is from 1 to 10,000.
-`plugins.anomaly_detection.max_running_entities_per_detector_for_historical_analysis` | 10 | The number of entity tasks that you can run in parallel for a single high cardinality detector. The task slots available on your cluster also impact how many entities run in parallel. If a cluster has 3 data nodes, each data node has 10 task slots by default. Say you already have two high cardinality detectors and each of them run 10 entities. If you start a single-flow detector that takes 1 task slot, the number of task slots available is 10 * 3 - 10 * 2 - 1 = 9. If you now start a new high cardinality detector, the detector can only run 9 entities in parallel and not 10. You can tune this value from 1 to 1,000 based on your cluster's capability. If you set a higher value, the anomaly detection plugin runs historical analysis faster but also consumes more resources.
+`plugins.anomaly_detection.max_running_entities_per_detector_for_historical_analysis` | 10 | The number of entity tasks that you can run in parallel for a single high cardinality detector. The task slots available on your cluster also impact how many entities run in parallel. If a cluster has 3 data nodes, each data node has 10 task slots by default. Say you already have two high cardinality detectors and each of them run 10 entities. If you start a single-entity detector that takes 1 task slot, the number of task slots available is 10 * 3 - 10 * 2 - 1 = 9. If you now start a new high cardinality detector, the detector can only run 9 entities in parallel and not 10. You can tune this value from 1 to 1,000 based on your cluster's capability. If you set a higher value, the anomaly detection plugin runs historical analysis faster but also consumes more resources.
 `plugins.anomaly_detection.max_cached_deleted_tasks` | 1,000 | You can rerun historical analysis for a single detector as many times as you like. The anomaly detection plugin only keeps a limited number of old tasks, by default 1 old task. If you run historical analysis three times for a detector, the oldest task is deleted. Because historical analysis generates a number of anomaly results in a short span of time, it's necessary to clean up anomaly results for a deleted task. With this field, you can configure how many deleted tasks you can cache at most. The plugin cleans up a task's results when it's deleted. If the plugin fails to do this cleanup, it adds the task's results into a cache and an hourly cron job performs the cleanup. You can use this setting to limit how many old tasks are put into cache to avoid a DDoS attack. After an hour, if still you find an old task result in the cache, use the [delete detector results API]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/api/#delete-detector-results) to delete the task result manually. You can tune this setting from 1 to 10,000.
 `plugins.anomaly_detection.delete_anomaly_result_when_delete_detector` | False | Whether the anomaly detection plugin deletes the anomaly result when you delete a detector. If you want to save some disk space, especially if you've high cardinality detectors generating a lot of results, set this field to true. Alternatively, you can use the [delete detector results API]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/api/#delete-detector-results) to manually delete the results.
 `plugins.anomaly_detection.dedicated_cache_size` | 10 | If the real-time analysis of a high cardinality detector starts successfully, the anomaly detection plugin guarantees keeping 10 (dynamically adjustable via this setting) entities' models in memory per node. If the number of entities exceeds this limit, the plugin puts the extra entities' models in a memory space shared by all detectors. The actual number of entities varies based on the memory that you've available and the frequencies of the entities. If you'd like the plugin to guarantee keeping more entities' models in memory and if you're cluster has sufficient memory, you can increase this setting value.