Go to All Forums

Change monitor action through API

The support level of our EC2 instances is defined by a tag on AWS level. We have 4 different actions defined, one for each support level.

What we want is change the defined action based on what support tag is added. So I was thinking a Python script that checks all instances, gets the support tags, and then set the actions attached to those monitors through the API.

So the question is: can one change the attached action of a monitor through the API, and how?
Like (2) Reply
Replies (14)

Hi Cloudar,

If you already have the monitors list based on tag for which you want to change actions, you can do it from our web client at Admin>Inventory>Bulk Action.
  • Select the monitors you want to apply/change action, and click on Bulk Action.
  • From the popup that opens, click on Modify Actions.
  • In the the form, select the monitors if it's not selected already, select the action from drop down and click on Add button.
  • Click on Save to submit your changes

You can also do this from bulk_action API.
Endpoint: /api/monitors/bulk_action
Request Method Type: PUT
Request Payload:

  1. {
      "monitors": [
        "123456789012345678",    //ID of monitor 1
        "123456789012345679",    //ID of monitor 2
        "123456789012345680"    //ID of monitor 3
      ],
      "bulk_action_type": 5,    //constant for altering actions
      "action_ids": [
        {
          "action_id": "123456789012345681",     //ID of action you want to apply
          "alert_type": 0    //execute on down
        }
      ]
    }


Possible value for alert type:
0 : Execute on Down
1 : Execute on Up
2 : Execute on Trouble
20: Execute on any attribute status change
-1: Execute on any status change

Aniket Sinha
Site24x7 Team
Like (0) Reply

Hi Aniket,

Thanks for the reply. It looks to be exactly what I needed. I did search the API documentation prior to posting, but I couldn't find this API call documented? Is it not there or am I looking in the wrong spot?


Thanks,
Tom
Like (0) Reply

Hello Tom,

You were looking at the right spot, but unfortunately this API is currently not documented.
We will document this API in the next update we do.

On a side note, were you trying to edit each monitor individually to set actions on them?
Like (0) Reply

Hi Aniket,

Thanks for your quick reply. As a matter of fact, I didn't try anything yet. I was reading through the API docs, and read that POST was not allowed for Server Monitors and EC2 Monitors, thereby assuming I could not update them through the API. I think that assumption was wrong, and that it can be done with a PUT.

Updating them in bulk to change the actions is the preferred way, I think, to reduce the amount of API calls. The only thing bothering me right now is determining the monitor_id for each monitor in order to be able to update them. We need to match EC2 instance names with monitor id's at site24x7 side. I don't see any other way right now then to pull the whole monitor list json and parse it. 

For type EC2INSTANCE, one could then match the instance id on AWS level with the instance_id on site24x7 level and for type SERVER match it with conf_instance_id. It's doable, just quite some work :)

Side question: for automatically added monitors like EC2INSTANCE and SERVER through client installations, is it possible to add a default action?
Like (0) Reply

Yes Tom, you need to pull the whole monitor list JSON and parse it to filter the monitors you need.

However, if you have tagged your EC2 Instances using Name tag, then we will pick that tag's value as display name in Site24x7, other wise default display name is the instance id. An ugly method of getting monitor id's is to use name based GET API. This is another undocumented API where you can get monitor details based on their display name. Here, you would make multiple API calls to get monitor id's. So, I wouldn't recommend using it.

This is the API end point in case you want take a look at it:
  1. https://site24x7.com/api/monitors/name/<displayName>
Answering your 2nd question, it's currently not possible to add a default action on EC2 monitors. Reason behind this is the parent AMAZON monitor itself doesn't support configuring Actions. We would take this as a feature request.

However, we have Configuration Template for Server monitors, but even that doesn't support actions currently. You can find it in web client  and read about it in help docs.
Like (0) Reply

It's a pity that one cannot add Actions as a default, as they are the only way to properly integrate with services like OpsGenie. And in autoscaling environments, newly spawned instances won't have any Actions (and thus alerting) attached.

The best way to consistently map EC2 instances and Servers to site24x7 monitors would be instance id. This is present for all type EC2INSTANCE monitors. However, for type SERVER I see some inconsistencies.

This one has got the required conf_instance_id key:

  1.     {
  2.       "ipaddress": "x.x.x.x",
  3.       "is_upgrade_available": false,
  4.       "monitor_id": "207093000000299023",
  5.       "conf_instance_id": "i-xxxxxxxx",
  6.       "resource_not_supported": false,
  7.       "threshold_profile_id": "207093000000030001",
  8.       "type": "SERVER",
  9.       "display_name": "server1",
  10.       "user_group_ids": [
  11.         "207093000000025003"
  12.       ],
  13.       "monitor_groups": [
  14.         "207093000000044719"
  15.       ],
  16.       "hostname": "server1.localdomain",
  17.       "log_needed": true,
  18.       "monitor_group_id": "207093000000044719",
  19.       "state": 0,
  20.       "notification_profile_id": "207093000000026001",
  21.       "server_type": "LINUX"
  22.     },

While this one hasn't:

  1.     {
  2.       "ipaddress": "x.x.x.x",
  3.       "is_upgrade_available": false,
  4.       "monitor_id": "207093000000082007",
  5.       "resource_not_supported": false,
  6.       "threshold_profile_id": "207093000000030001",
  7.       "type": "SERVER",
  8.       "display_name": "server2.localdomain",
  9.       "user_group_ids": [
  10.         "207093000000025003"
  11.       ],
  12.       "hostname": "server2.localdomain",
  13.       "log_needed": true,
  14.       "state": 0,
  15.       "notification_profile_id": "207093000000026001",
  16.       "server_type": "LINUX"
  17.     },

I don't see why that is.
Like (0) Reply

Hi Aniket,

Do you have any clue as to why for one SERVER monitor I get the "conf_instance_id" Key and for others I don't? It would be extremely useful if it were consistently present.
Like (0) Reply

Hi Tom,
Sorry for the time it took to analyze this.

The latest agent(v 16.1.0) installed on the instance sends the instance id only during initial setup. That's how you are getting the details of some servers.

There was an temporary issue at our end, due to which we missed to capture this information sent by the agents during initial setup.

To prevent this from happening, our next agent release will send the instance id again if it's not present in our systems already. This new agent version is already being tested and should be rolled out in a couple of weeks. Once released, please upgrade your server agents with the updated version, so that instance id will be captured for the missed servers.
Like (0) Reply

Hi Aniket,

Until the release of the new client, is there any way to update the info manually?
Like (0) Reply

Hello Tom,

We've made some changes in our system. Can you check if you're consistently receiving conf_instance_id in API response now?
Like (0) Reply

Hi Aniket,

Unfortunately not:

  1.     {
  2.       "ipaddress": "x.x.x.x",
  3.       "is_upgrade_available": true,
  4.       "monitor_id": "207093000000034003",
  5.       "resource_not_supported": false,
  6.       "threshold_profile_id": "207093000000030001",
  7.       "type": "SERVER",
  8.       "display_name": "serverx",
  9.       "user_group_ids": [
  10.         "207093000000025003"
  11.       ],
  12.       "monitor_groups": [
  13.         "207093000000044727"
  14.       ],
  15.       "hostname": "serverx.asp.int",
  16.       "log_needed": true,
  17.       "monitor_group_id": "207093000000044727",
  18.       "state": 0,
  19.       "notification_profile_id": "207093000000026001",
  20.       "server_type": "WINDOWS"
  21.     },
Like (0) Reply

Hi Tom,

This does not look good. Are you getting instance ids for Linux instances?
Windows server agent is yet to support this, and I'm afraid there is no manual way to update/patch this until we release the new agent for windows servers.
Like (0) Reply

Hi Aniket,

It is the same for Linux servers. Not all have the Key, but I have some more now.

I don't know it is related, but I see new monitors being added now to some servers. They are the same as an existing one, but have the instance ID attached to the Monitor Name. These two now have the conf_instance_id added. But there shouldn't be two monitors for 1 server. And for one the IP changed to 127.0.0.1...

  1.     {
          "ipaddress": "127.0.0.1",
          "is_upgrade_available": false,
          "monitor_id": "207093000000080019",
          "conf_instance_id": "i-xxxxxxxx",
          "resource_not_supported": false,
          "threshold_profile_id": "207093000000030001",
          "type": "SERVER",
          "display_name": "server1.localdomain",
          "user_group_ids": [
            "207093000000025003"
          ],
          "hostname": "server1.localdomain",
          "log_needed": true,
          "state": 0,
          "notification_profile_id": "207093000000026001",
          "server_type": "LINUX"
        },
        {
          "ipaddress": "127.0.0.1",
          "is_upgrade_available": false,
          "monitor_id": "207093000000436005",
          "conf_instance_id": "i-xxxxxxxx",
          "resource_not_supported": false,
          "threshold_profile_id": "207093000000030001",
          "type": "SERVER",
          "display_name": "server1.localdomain-i-xxxxxxxx",
          "user_group_ids": [
            "207093000000025003"
          ],
          "hostname": "server1.localdomain",
          "log_needed": true,
          "state": 0,
          "notification_profile_id": "207093000000026001",
          "server_type": "LINUX"
        },
Like (0) Reply

Hello Tom, 

I apologize for a delay. 

The temporary problem we had with the monitoring agent (v 16.1.0) was fixed and updated a new version online for a download. Please check and let me know if you have any further questions. 

Regards,
Rafee

Like (0) Reply

Was this post helpful?