Migrate from Control Center (Legacy)

You can migrate alerts, including triggers and actions, from Control Center (Legacy) to Control Center. Metric migration is not supported.

For more information about metrics, see Confluent Control Center Release Notes. To migrate alerts, see Alert migration API.

Warning

Do not install Control Center on the same node as Confluent Platform or any Confluent Platform data plane services, such as Schema Registry or REST Proxy. Install Control Center on a dedicated node. For more information, see Multi-Node Installation for Production.

Considerations:

• For clusters where historical metrics are of no value, you can shut down Control Center (Legacy) as soon as Control Center is up and running.

• For clusters where historical metrics are needed (say, for a period of N days), consider the following recommendations:

  • Run both Control Center (Legacy) and Control Center simultaneously for N days.

  • Control Center (Legacy) users should continue using Control Center (Legacy) until the N days of history is populated in Control Center.

  • After historical metrics are available in Control Center, you can shut down Control Center (Legacy) and move users to Control Center.

Alert migration API

Control Center includes APIs to migrate alerts (triggers and actions) from Control Center (Legacy) to Control Center. Use these APIs to migrate your existing Control Center (Legacy) triggers and actions onto Control Center.

Migrate alerts

Use curl on Control Center to migrate alerts. Alerts include triggers and actions. Triggers come from the command topic on Control Center (Legacy) and are added to Alertmanager on Control Center.

Considerations:

• Alert migration API returns 401 Unauthorized if you lack the required permissions. For more information, see Authenticate to migrate alerts.

• If a trigger fails, migration continues for the remaining triggers. The response lists the triggers that were migrated, skipped, or failed.

• Control Center skips triggers that Prometheus mode does not support, for example, ACTIVE_CONTROLLER_COUNT. The response lists these triggers in the skipped field.

• Alerts that are not supported by Control Center are not migrated from Control Center (Legacy). For more information, see Control Center Alerts for Confluent Platform.

  • Alerts for ZooKeeper disconnected are not migrated.

  • Triggers with average latency (ms) metric for consumer groups

  • Triggers with consumer lead metric for consumer groups

  • Triggers with consumption difference metric for consumer groups

  • Triggers with maximum latency (ms) metric for consumer groups

Authenticate to migrate alerts

If you use role-based access control (RBAC) you must have superuser access to migrate alerts. For more information, see Use Predefined RBAC Roles in Confluent Platform.

To use curl as superuser, navigate to Control Center as superuser, then use developer tools from your browser to access the authorization header. Use the authorization header to authenticate curl.

To use an authorization header to authenticate

1. Log in to Control Center.

2. From your browser, access the developer tools (In Chrome, for example, press F12).

3. Navigate to Network, select any Fetch/XHR request, then from Request Headers, copy the authorization header to your clipboard.

4. Use the authorization header to make the curl request.

   curl --location --request POST 'https://ec2-52-11-17-175.us-west-2.compute.amazonaws.com:9021/3.0/alerts/triggers/migrate-triggers' \
        --header 'authorization: Bearer {authorization_header}'
   

To migrate triggers

1. Use Verification API to check for differences.

   curl --location 'http://localhost:9021/3.0/alerts/triggers/migration/status'
   

   The response has HTTP status 200 and lists triggers in three arrays:

   • migrated: Triggers that Control Center already migrated.

   • skipped: Triggers that Control Center does not migrate because Prometheus mode does not support them. The reason field gives the cause.

   • failed: Triggers that are waiting for migration. Tells users to run the Migrate triggers API next.

   {
     "migrated": [{"guid": "0000a000-b000-0000-a0ae-fbdd00e00000", "name": "trigger-1", "metric": "UNDER_REPLICATED_PARTITIONS"}],
     "skipped": [],
     "failed": []
   }
   

   If all three arrays are empty, there are no triggers to report.

2. Migrate triggers using the Migrate triggers API.

   curl --location --request POST 'http://localhost:9021/3.0/alerts/triggers/migrate-triggers'
   

   The response has HTTP status 200 and lists each trigger in one of three arrays:

   • migrated: Control Center created a Prometheus rule for the trigger.

   • skipped: Prometheus mode does not support the trigger metric, for example, ACTIVE_CONTROLLER_COUNT. Control Center does not migrate these triggers. You do not need to take action.

   • failed: Control Center could not create a Prometheus rule for the trigger. The reason field gives the cause. For example, the trigger refers to a cluster that Control Center does not know.

   If a trigger fails, Control Center continues to migrate the other triggers.

3. Use Verification API to check for differences.

   curl --location 'http://localhost:9021/3.0/alerts/triggers/migration/status'
   

To migrate actions:

1. Use Verification API to check for differences.

   curl --location 'http://localhost:9021/3.0/alerts/actions/migration/status'
   

   • If you don’t see any differences, the previous install of Control Center (Legacy) did not have any actions or Control Center may already contain the necessary actions.

   • If actions are pending migration, you get a failure response, and that means that actions are available to migrate. Use the Migrate actions API.

     {"status":"failure","missing_actions from receivers: ":["0000a000-b000-0000-a0ae-fbdd00e00000"]}
     

   • If actions are already migrated, you get a success message.

     {"status":"success"}
     

2. Migrate actions using the Migrate actions API.

   curl --location --request POST 'http://localhost:9021/3.0/alerts/actions/migrate-actions'
   

3. Use Verification API to check for differences.

   curl --location 'http://localhost:9021/3.0/alerts/actions/migration/status'
   

   If the status returns success, the actions migration is complete.

API reference

This is the reference for the Alert Migration API.

Migrate triggers

Migrates triggers from the command topic to Prometheus.

Endpoint:

POST /3.0/alerts/triggers/migrate-triggers

Sample curl:

curl --location --request POST 'http://localhost:9021/3.0/alerts/triggers/migrate-triggers'

Response codes:

Response code	Description
200	Successful migration
401	Unauthorized (requires superuser privileges when RBAC is enabled)
500	Internal server error during migration

Example Response:

The response returns HTTP status code 200. If a trigger fails, migration continues for the remaining triggers. The response lists each trigger in the migrated, skipped, or failed fields. Control Center skips triggers that Prometheus mode does not support, for example, ACTIVE_CONTROLLER_COUNT. Use the reason field to determine why a trigger failed or was skipped.

{
  "migrated": [{"guid": "...", "name": "...", "metric": "..."}],
  "skipped":  [{"guid": "...", "name": "...", "metric": "...", "reason": "..."}],
  "failed":   [{"guid": "...", "name": "...", "metric": "...", "reason": "..."}]
}

Verify trigger migration

Verifies the status of trigger migration by comparing triggers in the command store with those in Prometheus.

Endpoint:

GET /3.0/alerts/triggers/migration/status

Sample curl:

curl --location 'http://localhost:9021/3.0/alerts/triggers/migration/status'

Response codes:

Response code	Description
200	Verification complete
401	Unauthorized (requires superuser privileges when RBAC is enabled)
500	Verification failed

Example Response:

The response body is the same as the response from the Migrate triggers API. Control Center skips triggers that Prometheus mode does not support and lists them in the skipped array. The failed array contains triggers which are not migrated.

{
  "migrated": [{"guid": "...", "name": "...", "metric": "..."}],
  "skipped":  [{"guid": "...", "name": "...", "metric": "...", "reason": "..."}],
  "failed":   [{"guid": "...", "name": "...", "metric": "...", "reason": "..."}]
}

Migrate actions

Migrates all actions from the command topic to Alertmanager.

Endpoint:

POST /3.0/alerts/actions/migrate-actions

Sample curl:

curl --location --request POST 'http://localhost:9021/3.0/alerts/actions/migrate-actions'

Response Codes:

Response code	Description
200	Successful migration
401	Unauthorized (RBAC is enabled and you are not a superuser)
500	Internal server error during migration

Example Response (Success):

• No response body

200 OK

Verify action migration

Verifies the status of action migration by comparing actions in the command store with those in Alertmanager.

Endpoint:

GET /3.0/alerts/actions/migration/status

Sample curl:

curl --location 'http://localhost:9021/3.0/alerts/actions/migration/status'

Response codes:

Response code	Description
200	Verification complete
500	Verification failed

Example Responses:

Success:

{
"status": "success"
}

Failure (Missing Actions):

{
"status": "success",
"missing_actions from receivers: ": ["action-guid-1"]
}

Related content

• Multi-Node Installation for Production

• Control Center Alerts for Confluent Platform

• Configure RBAC for Control Center on Confluent Platform