Query on API - V1 to V2

[smartpraseetha]

Hello 

I have a custom script which stops the monitoring on the hosts based on some conditions.

I am using 2 APIS the first API gets all the hosts - /entity/infrastructure/hosts/ and I made an iteration in a loop that it gets entity {id} for each host and it feeds that to the second API v1  - /api/config/v1/hosts/{id}/monitoring

That is now V1 versions are in the  Deprecated state.

The alternate option given is to Manage host monitoring settings for /api/config/v1/hosts/{id}/monitoring is  via the settings endpoint with schemaId builtin:host.monitoring instead. But I dont get to see the same results to get the ways to pass the entity id nor get  the monitoring configuration of OneAgents.

I am wondering what is the purpose of schema and how could we use in the same level as the previous API ?

Also is there any reference that I  can have the API -  /api/config/v1/hosts/{id}/monitoring  in  V2 version  ?

[PedroSantos · Accepted solution]

If I am understanding your question properly, you're aiming to use the V2 API for the same purpose you used the V1, which in this case is to disable host monitoring based on certain conditions with a custom script.

I know this endpoint works for fetching hosts:

curl -X GET "https://{environmentid}.live.dynatrace.com/api/v2/entities?entitySelector=type(HOST)" \
-H "Authorization: Api-Token <your-api-token>"

Then, you can use the settings/objects with the builtin:host.monitoring schema to update settings on a specific host.

---

@smartpraseetha wrote:

I am wondering what is the purpose of schema and how could we use in the same level as the previous API ?

Also is there any reference that I  can have the API -  /api/config/v1/hosts/{id}/monitoring  in  V2 version  ?

---

Here's a python script I've successfully used before to disable monitoring of hosts based on a condition, using the V2.

Essentialy, V2 uses a structured approach where settings are managed via configurations (schemas and settings objects).

import requests
import json

# Dynatrace environment and API token
dt_env = "placeholder"
api_token = "placeholder"

# Headers for API requests
headers = {
    "Authorization": f"Api-Token {api_token}",
    "Content-Type": "application/json"
}

# Define the condition function before using it
def some_condition(host):
    # Implement your condition logic here
    # Example: Disable monitoring for all hosts
    return True

# Step 1: Get all hosts (requires entities.read permission)
hosts_url = f"https://{environmentid}.live.dynatrace.com/api/v2/entities?entitySelector=type(HOST)"
response = requests.get(hosts_url, headers=headers)
if response.status_code == 200:
    hosts = response.json().get('entities', [])
    print("Fetched Hosts:")
    print(json.dumps(hosts, indent=2))
else:
    print(f"Failed to fetch hosts: {response.status_code} - {response.text}")
    hosts = []

# Step 2: Iterate over hosts and disable monitoring (requires settings.write permission)
for host in hosts:
    host_id = host['entityId']
    print(f"Processing host {host_id}")
    
    # Check some condition to decide whether to disable monitoring
    if some_condition(host):
        # Disable monitoring for the host
        settings_url = f"https://{environmentid}.live.dynatrace.com/api/v2/settings/objects"
        payload = [
            {
                "schemaId": "builtin:host.monitoring",
                "scope": host_id,  
                "value": {
                    "enabled": False  
                }
            }
        ]
        response = requests.post(settings_url, headers=headers, json=payload)
        if response.status_code == 200:
            print(f"Monitoring disabled for host {host_id}")
        else:
            print(f"Failed to disable monitoring for host {host_id}: {response.status_code} - {response.text}")
    else:
        print(f"Condition not met for host {host_id}, monitoring remains enabled")

[smartpraseetha]

Hello @PedroSantos 

My view here is that  these changes of APIS to schemas seems to be not very useful to meet a variety of extracts with conditions. In my case it doesn't allow to have the several filters or conditions based on the parent API which I intended.

Example the host monitoring API referred here  - I couldn't ( use multiple conditions) example  to use my hosts in iteration mode - Condition to check monitoring mode and monitoring state 2 conditions, to make this logic effective I need to call 2 schemas which i found making the logic extensive. So I moved ahead with 1 condition to check only monitoring state from the API -hosts_url = f"https://{environmentid}.live.dynatrace.com/api/v2/entities?pageSize=1000&entitySelector=type(HOST)mzID()&from=now-1h&fields=properties.STATE

Take those hosts based on that condition then iterate it, there was the problem  i found it complicated as the schemas with GET and POST on have different values expected to be passed in the JSON.

This was my GET API  - https://environment/api/v2/settings/objects?schemaIds=builtin%3Ahost.monitoring&fields=objectId%2Cva... 

$payload= @{schemaId=$builtinmonitoring
scope=$host_id
value=@{enabled=$enabled}
}|ConvertTo-Json

Write-host $payload
$response = Invoke-RestMethod -Uri $settings_url -Headers $headers -Method Post -Body $payload

And my POST API  as $response with JSON body of the request as below. Which means the results of  GET Schema  with the value.enabled  cannot be passed to Stop the monitoring using POST or PUT 

settings/objects

[  {
    "externalId": "string",    "insertAfter": "Y2ktaGd=",    "objectId": "Y2ktaGd",    "schemaId": "builtin:container.built-in-monitoring-rule",    "schemaVersion": "1.0.0",    "scope": "HOST-D",    "value": {      "autoMonitoring": true
    }
  }
]

There is no object called value.enabled = false like in GET  to be passed to POST/PUT  as there it is referred as 

"value": {    "autoMonitoring": true

 It seems to be more complicated for simple logics. Can you guide how to use schema with  GET and POST in stopping monitoring of the hosts ?

[smartpraseetha]

@PedroSantos Thank you very much for the insights on the schema id so that means its needs to be combined with another api /api/v2/settings/objects" to pass the entity ids. It is clear to me now.