Detection Alerts Migration API
editDetection Alerts Migration API
editAfter an upgrade of Kibana, the latest Elastic Security features will be available for any new detection alerts that are generated. However, in order to enable new features on existing detection alerts, migration may be necessary. See Release Notes for instructions specific to your upgrade.
Migrating detection alerts is performed at the index level and requires the following steps:
Determine which indices to migrate
editYou can use the Migration Status API to determine which indices contain detection alerts of a particular age, along with migration info for each of those indices.
Request
editGET <kibana host>:<port>/api/detection_engine/signals/migration_status?from=now-30d
Request query parameters
editName | Type | Description |
---|---|---|
|
datemath |
Maximum age of qualifying detection alerts |
Response example
edit{ "indices": [ { "index": ".siem-signals-default-000002", "version": 15, "signal_versions": [ { "version": 15, "count": 100 }, { "version": 16, "count": 87 } ], "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "status": "pending", "version": 16, "updated": "2021-01-06T20:41:37.173Z" } ], "is_outdated": true }, { "index": ".siem-signals-default-000003", "version": 16, "signal_versions": [ { "version": 16, "count": 54 } ], "migrations": [], "is_outdated": false } ] }
The above response shows two indices: .siem-signals-default-000002
is outdated, with multiple versions of detection alerts and a pending migration, and .siem-signals-default-000003
, which is up to date as the current write index.
Indices that do not contain detection alerts in the specified range will be filtered from the response.
With the above info, we can compile a list of indices that we wish to migrate.
Initiate migrations
editMigrations are initiated per index. While the process is neither destructive nor interferes with existing data, it may be resource-intensive. As such, it is recommended that you plan your migrations accordingly.
Request
editPOST <kibana host>:<port>/api/detection_engine/signals/migration
Request body
editName | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of index names to migrate |
Yes |
|
Integer |
Number of alerts to migrate per batch. Corresponds to the |
No |
|
Integer |
The throttle for the migration task in sub-requests per second. Corresponds to |
No |
|
Integer |
The number of subtasks for the migration task. Corresponds to |
No |
Response example
edit{ "indices": [ { "index": ".siem-signals-default-000001", "migration_id": "923f7c50-505f-11eb-ae0a-3fa2e626a51d", "migration_index": ".siem-signals-default-000001-r000016" } ] }
The response will include, for each index specified, an ID and destination index for the migration, and an error if unsuccessful.
Finalize migrations
editThe finalization endpoint replaces the original index’s alias with the successfully migrated index’s alias. The endpoint is idempotent; therefore, it can safely be used to poll a given migration and, upon completion, finalize it.
The original indices are not removed as part of this step. After verifying the integrity of the migrated index, you can use the Migration cleanup endpoint to apply a 30-day deletion policy to the original, outdated index.
If an unsuccessful migration is finalized, a deletion policy will be applied to its index, causing it to be deleted after 30 days.
Request
editPOST <kibana host>:<port>/api/detection_engine/signals/finalize_migration
Request body
editName | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of `migration_id`s to finalize |
Yes |
Response example
edit{ "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "completed": true, "destinationIndex": ".siem-signals-default-000002-r000016", "status": "success", "sourceIndex": ".siem-signals-default-000002", "version": 16, "updated": "2021-01-06T22:05:56.859Z" } ] }
Finalized migrations will show a response of completed: true
, with a corresponding status
. If the migration is still running when you attempt to finalize it, its response will show as completed: false
.
Migration cleanup
editMigrations favor data integrity over shard size. Consequently, unused or orphaned indices are artifacts of the migration process. A successful migration will result in both the old and new indices being present. As such, the old, orphaned index can (and likely should) be deleted.
While you can delete these indices manually, the endpoint accomplishes this task by applying a deletion policy to the relevant index, causing it to be deleted after 30 days. It also deletes other artifacts specific to the migration implementation.
Request
editDELETE <kibana host>:<port>/api/detection_engine/signals/migration
Request body
editName | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of `migration_id`s to finalize |
Yes |
Response example
edit{ "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "destinationIndex": ".siem-signals-default-000002-r000016", "status": "success", "sourceIndex": ".siem-signals-default-000002", "version": 16, "updated": "2021-01-06T22:05:56.859Z" } ] }
The response will include all migrations that were successfully deleted.