23 Dec 2024
01:44 PM
- last edited on
30 Dec 2024
07:18 AM
by
MaciejNeumann
In extensions framework I can't use groups and devices any more.
Therefor I need to create a topology for the definition here below that I need to add in the extension.yaml file
10 Jan 2025 10:24 AM
In Extension Framework 2 the way to define topology changed completely. You now need to define your topology in the extension.yaml file to match the metrics you are sending from your code.
Have a look at this thread for an example and explanation on how you could do it.
13 Jan 2025 11:05 AM
Thanks for this example, but I was already aware that we need to add a topology in the extension.yaml file.
My question is HOW I can do this?
19 Dec 2025 11:09 AM
Hi Jannick,
I must have somehow missed your original reply, sorry about that.
Not sure if you already figured out how to make this work, but for anyone else who might stumble upon this thread:
This generic topology works by defining entities from metrics and logs, as opposed to the old one which worked by first defining the entity and then the attaching metrics and logs to it.
On the YAML you defined a set a rules. Each rule defines and idPattern which is how the entity ID will be calculated, and sources, which is what metrics/logs are going to create this entity. These are the most important fields. Let's give a very simple example:
topology:
types:
- enabled: true
name: unifi-device
displayName: Unifi device
rules:
- idPattern: unifi_device_{device.name}
instanceNamePattern: {device.name}
sources:
- sourceType: Metrics
condition: $prefix(unifi.)
With this topology definition, for every metric whose key starts with unifi. which has the dimension device.name (here the dimension is implicitly required because you are using it in the idPattern), Dynatrace will calculate an ID hash from the string unifi_device_{device.name} (where it replaces device.name with the actual value of the dimension in your metric). Then, if no entity with that ID exists in your environment, it will create a new one. Otherwise, it will attach this metric to the existing entity.
You can then enrich this with properties:
topology:
types:
- enabled: true
name: unifi-device
displayName: Unifi device
rules:
- idPattern: unifi_device_{device.name}
instanceNamePattern: {device.name}
sources:
- sourceType: Metrics
condition: $prefix(unifi.)
attributes:
- pattern: '{mac}'
key: mac
displayName: MAC address
- pattern: '{type}'
key: type
displayName: Device type
- pattern: '{adopted}'
key: adopted
displayName: Adopted
where the rule will now try to extract as properties the dimensions mac, type and adopted from the matching metrics (if these dimensions exist).
A strategy that we normally use in our extension to populate this attributes, is to have a "dummy" metric like unifi.device.attributes which we populate with all the dimensions that should be attributes, and then have as our first rule something with this source:
sourceType: Metrics
condition: $eq(unifi.device.attributes)
Let me know if that was helpful, and once again apologies for the very delayed reply.
Featured Posts