topic Re: Query on API - V1 to V2 in Dynatrace API

Query on API - V1 to V2

smartpraseetha — Fri, 12 Jul 2024 12:56:42 GMT

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 ?

Re: Query on API - V1 to V2

PedroSantos — Tue, 09 Jul 2024 17:25:07 GMT

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")

Re: Query on API - V1 to V2

smartpraseetha — Wed, 10 Jul 2024 07:29:48 GMT

@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.

Re: Query on API - V1 to V2

smartpraseetha — Tue, 03 Sep 2024 12:20:44 GMT

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%2Cvalue%2Csummary%2Cscope&filter=value.enabled%20%3D%20true&pageSize=500

$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 ?

Re: Query on API - V1 to V2

MarwanC — Thu, 05 Jun 2025 11:57:26 GMT

This good if you have control to introduce a man in the middle and deliver this component in Python, However, we are depending on api/v1/entity/infrastructure/hosts to use it an extract in our CMDB, are you sure there is no v2 of the one call approach.