It seems like your cluster was not in a consistent state. Ambari needs to know what repository/version your cluster is "CURRENT" on. We track this via the cluster_version table. There will be a bunch of entries in here, one for each repository you've ever installed. It's OK for most of them to be OUT_OF_SYNC - that's expected. However, exactly 1 must be "CURRENT". I would find your correct repository version from the repo_version table and then update the corresponding row in the cluster_version table. Something like this: UPDATE cluster_version SET state = 'CURRENT' WHERE repo_version_id = <some-id>; ... View more

You can clear out an individual alert's state by disabling it and then re-enabling it. This will cause all active instances of that alert to disappear and it will run clean. On some versions of Ambari, this was required when you did things like delete a host which could leave orphaned alerts which never run again (and thus become stale). If you are seeing the actual "Stale Alert" trigger, you'll want to identify which alerts are causing it to fire - in other words, which alerts are not running. Disabling/Enabling those could help - but if they seem to continue to be stale, then something else is going on which is preventing them from running. ... View more

There are several alerts which cover heap. For example, if you wanted to see the raw DataNode heap value, then you'd check the metric alert definition for it: https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/alerts.json#L1714-L1755 For NameNode, we don't alert on heap directly but we measure average heap deviation values: https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/alerts.json#L868-L947 https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/alerts/alert_metrics_deviation.py ... View more

The JSON of the alert definition must have an invalid property set on it. Not sure how it happened, but there are a couple of options: Find the offending alert definition and correct its JSON in the database. Chances are it's the one after yarn_app_timeline_server_webui. Just remove all alert data and have Ambari bootstrap the definitions back in from the stack. This is a good option if you haven't added or modified any alert definitions from the ones that ship with the product. ... View more

You'll need to re-generate certificates on the Ambari Server since they are expired: https://community.hortonworks.com/articles/68799/steps-to-fix-ambari-server-agent-expired-certs.html ... View more

You're hitting an issue with Ambari Server Upgrade from 2.4.2 to 2.5.0.3 - as part of this upgrade, we need to drop and re-create the primary key on the hostcomponentdesiredstate table. The error you're getting indicates that the primary key already exists and thus can't be added again. In your logs, you might see something like this statement: Unable to determine the primary key constraint name for hostcomponentdesiredstate I'd like to know why this might be happening (could be an artifact of how your Oracle DB is installed). In any event, you should be able to correct this by hand and re-run the upgrade: ALTER TABLE hostcomponentdesiredstate DROP CONSTRAINT PK_hostcomponentdesiredstate; ALTER TABLE hostcomponentdesiredstate ADD CONSTRAINT PK_hostcomponentdesiredstate PRIMARY KEY (id); Now you can retry "ambari-server upgrade" ... View more