Can you provide an example of the POST you're using to create the definition. 
This might be a bug that needs to be fixed.

To answer your question, it might get converted to a float in JSON responses 
because their default serializers don't know if it's a double or an integer. 
But when you create your alert, you can send it as an integer and that should 
prevent any parsing problems.

On Apr 13, 2016, at 8:49 AM, Henning Kropp 
<[email protected]<mailto:[email protected]>> wrote:

To follow up. I believe that the default_port is causing the issue. Why is it a 
float?

The error appeared even with DELETE. So my assumption is, since I had disabled 
alerts, due to parsing errors, for HDFS they were parsed again. Could this be?

I submited alert definitions with default_port: 0.0 without issues, but they 
never registered with any host. Once I removed the default_port from the source 
description, it was fine.

All with Ambari 2.2

Regards

Am 06/04/16 um 18:52 schrieb Jonathan Hurley:

This is an artifact of how Gson does its conversion. There were several bugs 
fixed in Ambari around this. I'm guessing you have an older version and may be 
hitting AMBARI-11566? In any event, can you provide the POST which created the 
definition?


On Apr 6, 2016, at 12:10 PM, Henning Kropp 
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
 wrote:

Ok, since I was getting back a 200 reply I didn't check the logs. I get the 
below error for no apprent reason. During try and error I removed almost all 
fields in a PUT request, while still getting the below error. What I noticed 
also is, that "default_port" is returned as a float but defined as an int 
AlertUri.class

com.google.gson.JsonSyntaxException: java.lang.NumberFormatException: For input 
string: ".0"
        at 
com.google.gson.internal.bind.TypeAdapters$7.read(TypeAdapters.java:232)
        at 
com.google.gson.internal.bind.TypeAdapters$7.read(TypeAdapters.java:222)
        at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:93)
        at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:172)
        at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:93)
        at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:172)
        at com.google.gson.Gson.fromJson(Gson.java:795)
        at com.google.gson.Gson.fromJson(Gson.java:859)
        at com.google.gson.Gson$2.deserialize(Gson.java:131)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionFactory$AlertDefinitionSourceAdapter.deserialize(AlertDefinitionFactory.java:350)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionFactory$AlertDefinitionSourceAdapter.deserialize(AlertDefinitionFactory.java:294)
        at com.google.gson.TreeTypeAdapter.read(TreeTypeAdapter.java:58)
        at com.google.gson.Gson.fromJson(Gson.java:795)
        at com.google.gson.Gson.fromJson(Gson.java:761)
        at com.google.gson.Gson.fromJson(Gson.java:710)
        at com.google.gson.Gson.fromJson(Gson.java:682)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionFactory.coerce(AlertDefinitionFactory.java:195)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionHash.getAlertDefinitions(AlertDefinitionHash.java:240)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionHash.enqueueAgentCommands(AlertDefinitionHash.java:490)
        at 
org.apache.ambari.server.state.alert.AlertDefinitionHash.enqueueAgentCommands(AlertDefinitionHash.java:460)
        at 
org.apache.ambari.server.events.listeners.alerts.AlertHashInvalidationListener.onAmbariEvent(AlertHashInvalidationListener.java:94)
        at sun.reflect.GeneratedMethodAccessor225.invoke(Unknown Source)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at 
com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
        at com.google.common.eventbus.EventBus.dispatch(EventBus.java:314)
        at 
com.google.common.eventbus.AsyncEventBus.access$001(AsyncEventBus.java:34)
        at 
com.google.common.eventbus.AsyncEventBus$1.run(AsyncEventBus.java:100)
        at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NumberFormatException: For input string: ".0"
        at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:569)
        at java.math.BigInteger.<init>(BigInteger.java:461)
        at java.math.BigInteger.<init>(BigInteger.java:597)
        at 
com.google.gson.internal.LazilyParsedNumber.intValue(LazilyParsedNumber.java:41)
        at com.google.gson.JsonPrimitive.getAsInt(JsonPrimitive.java:255)
        at 
com.google.gson.internal.bind.JsonTreeReader.nextInt(JsonTreeReader.java:197)
        at 
com.google.gson.internal.bind.TypeAdapters$7.read(TypeAdapters.java:230)
        ... 30 more

Am 06/04/16 um 16:33 schrieb Jonathan Hurley:
Alerts are automatically distributed to all hosts which match their service and 
component. So, if you created your alert definition with HDFS and NameNode, 
then Ambari will automatically push this alert definition to any host that's 
running NameNode. The host will begin running the alert automatically. There's 
really nothing that you need to do here; the alert framework handles everything 
for you.

On Apr 6, 2016, at 9:35 AM, Henning Kropp 
<[email protected]<mailto:[email protected]>> wrote:

Actually I added a alert definition (via REST), but it does not have any 
Service/Host attached, so I was wondering how are hosts "attached" to an alert 
defintion?

It's an alert for HDFS, NAMENODE, so the definition on POST contained the 
component and service attributes, which would be enough information to 
distribute the alert on the corresponding hosts?

Sorry for the confusion. In my search for an answer I came accross the 
host-only alerts and thought it was related.

Thanks again for your help.

Regards,
Henning

Am 06/04/16 um 15:26 schrieb Jonathan Hurley:
I think what you're asking about is a concept known as host-level alerts. These 
are alerts which are not scoped by any particular hadoop service. A good 
example of this is the disk usage alert. It's bound only to a host and will be 
distributed and run regardless of what components are installed on that host.

There are two ways to add a host alert:
1) Edit the alerts.json under /var/lib/ambari-server/resources and add your new 
alert to the "AMBARI_AGENT" component.
2) Use the REST APIs to create your new alert. The service should be "AMBARI" 
and the component should be "AMBARI_AGENT".

You can use the current agent alert (disk usage) as an example:
https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/alerts.json#L31

On Apr 6, 2016, at 8:56 AM, Henning Kropp 
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
 wrote:

How can an alert be added to a host?


Am 05/04/16 um 18:41 schrieb Henning Kropp:
Worked now. Thanks.

Am 05/04/16 um 18:01 schrieb Jonathan Hurley:
The alerts.json file is only to pickup brand new alerts that are not currently 
defined in the system. It's more of a way to quickly seed Ambari with a default 
set of alerts. If the alert has already been created, any updates for that 
alert made in alerts.json will not be brought in. You'll need to use the REST 
APIs to update existing definitions.

You are correct that the agents run the alerts. The definitions.json file on 
each agent shows what alerts it is trying to run.

On Apr 5, 2016, at 11:46 AM, Henning Kropp 
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
 wrote:

Hi,

I am currently trying to change the alert definitions. I used the REST api to 
put a new definition for example for id /30 . I can see the changes when doing 
a GET.

Additionaly I replaced the alert.json of the service under ambari-server and 
ambari-agent. Still the changes are not reflected in 
/var/lib/ambari-agent/cache/alerts/definition.json and I suspect the alert is 
not working as expected because of this.

As I undestand the defintions are broadcasted with heartbeats by the server? 
And are executed on the host by the agent, where the service is running? Right?

What am I missing?

Thanks,
Henning














Reply via email to