Migration Considerations

This page covers important considerations for Platform Operators when transitioning to a9s Prometheus 3. For information about migrating between a9s Prometheus 2 Service Instances, refer to Migration within a9s Prometheus 2 Service Instances.

Migrating from a9s Prometheus 2 to a9s Prometheus 3

No In-Place Upgrade

a9s Prometheus 3 is a new version of the a9s Prometheus Data Service. There is no supported migration path or in-place upgrade from a9s Prometheus 2 to a9s Prometheus 3. You must provision a new a9s Prometheus 3 Service Instance independently.

Data and Configuration Migration

• Historical metrics data (the Prometheus TSDB) is not carried over. The new Service Instance starts with an empty time-series database. Metrics previously stored in the a9s Prometheus 2 Service Instance will not be migrated to the a9s Prometheus 3 Service Instance.
• Custom Grafana dashboards from the old Service Instance must be migrated manually to the new Service Instance. Default dashboards that have not been modified do not require migration.
• Custom Grafana alerts, including alert rules, contact points, notification policies, silences, and groups cannot be imported directly into the new Service Instance. Refer to the official Grafana Alerting documentation to manually migrate your custom alerts.
• Several Grafana plugins that were previously available in a9s Prometheus 2 are no longer available in a9s Prometheus 3. Dashboards that rely on any of these plugins must be updated during migration. The removed plugins are:
  • Grafana Status Panel
  • Clock Panel
  • Diagram Panel
  • Worldmap Panel
  • Worldping App
  • Histogram Panel

For the full transition procedure, see the Application Developer Migration Guide.

Important Changes

The following changes may require action when transitioning to a9s Prometheus 3:

• The --alertmanager.timeout flag has been removed. If this setting was configured via custom parameters, it will no longer have any effect.
• Alert rules are now consolidated under the anynines_alerts job. If custom alert rule file paths are configured, update them to reference /var/vcap/jobs/anynines_alerts/*.alerts.yml.
• When provisioning a new a9s Prometheus 3 Service Instance for the migration, the Grafana contact points ops file should be considered. For more information, see Grafana Contact Points.

For a full list of changes in Prometheus 3, refer to the Prometheus 3.0 migration guide.

Migration within a9s Prometheus 2 Service Instances

Plan compatibility when migrating between a9s Prometheus 2 Service Instances

In order to allow the migration of a9s Prometheus Service Instances, you must ensure that the destination service plan has the same resources as the origin service plan (e.g. from a -small plan to another -small plan).

Thus, the default placeholder values such as vm_type, persistent_disk_type should be exactly the same; as upgrading to another, larger service plan, regardless of the type of plan and used template is not possible.