Shine some light on the new "Generic Topology Model"

[r_weber]

Has anyone from the Dynatrace Team some more info on the new feature "Topology Model"?

Since it's already there I wanted to tap into it to e.g. map out some kind of network routing topology maybe?

Nothing in the docs or in any blogpost, seems like a featureflag that was turned on without any purpose 🙂

[dave_mauney · Accepted solution]

It’s for defining a custom topology to deal with custom metrics.  Here is some information from help on the subject:  https://www.dynatrace.com/support/help/how-to-use-dynatrace/metrics/metric-ingestion/topology-model/...

[Anonymous]

That looks crazy powerful.... Awesome.

[r_weber]

Thanks! Last time I checked the Documentation wasn't there yet.
It also seems a bit 'outdated' some of the UI sections are not well described.

I tried to set up some relationships as described here:

I'm testing with data ingests like this:

threesixtyperf.network.tracert,src=<ip>,dst=<ip> 200

Basically measuring the latency for route hops. To do that I thought of defining entities with relationships between eachother (mapping the route): src calls dst - which would map the routing path/dependency.

I'm able to get the custom entities, as confirmed by the entity API:

And entities like this:

But I'm struggling with getting the relationship "calls" working. As per above description you need to define two extraction rules with different roles but the same entity type:

As per the documentation:

With the above example, two service instances of the same service type should be extracted and combined with a call relationship.

In this case, one extraction rule has to be identified with a role (caller) and the other extraction with a different role (callee).

During the extraction of the relationship, the caller and callee role can then be used to specify the direction of the resulting relationship.

I understand this as I need to define two extraction rules for the Generic Entity Type like this to define a role for "src" and one for "dst", so I can link the two with a call relationship.

However in such a case the first rule will always match and thus the second will not be evaluated (note the remark in the screenshot that only one rule will be evaluated. So one entity cannot be "src" and "dst" at the same time. Also the example from the documentation (caller and callee)  would not work if you want to model call dependencies like service1 -> service2 -> service3.

Maybe I'm missing something, but how would this work?

Thanks,

Reinhard

[dave_mauney]

Here is another reference in help:  https://www.dynatrace.com/support/help/shortlink/topology-model#custom-topology-model

[wolfgang_beer · Accepted solution]

Help documentation is here:

So far it's an API first feature, as the Dynatrace UIs for showing those custom entity types will come in one of the next releases.

As our newly introduced Extensions framework uses this possibility to define custom topology types and relationships, we decided to also show the new feature transparently in the settings, even if the UI is coming later.

I agree that my help on 'roles' is a bit thin, I will see to extend it to show the full configured screen and for what it is used.

In short, the roles are used to distinguish two instances of the same type, in case they appear in the same metric lines, as in your example with the three performance.

Best regards,

Wolfgang 

[r_weber]

HI @wolfgang_beer ,

I'm diving a bit deeper into this but I still haven't managed to get the roles (dependency between two entities of the same type) to work. It would be great to get a working example for this!

Thanks,

Reinhard 

[thomas_brandl]

Hi Reinhard,

I will briefly talk about this in tomorrow's Partner Tech Update: https://info.dynatrace.com/global_all_wc_tech_update_series_15977_registration.html 

Thomas

[r_weber]

Funny to see you're back at Dynatrace again! You might remember me under a different name though....was is 2012 when you left the lab? 🙂

[thomas_brandl]

Of course I remember 😁

Yep, left the lab in 2012, joined again in 2019 - you always get to meet each other twice!

[sandorbihary]

Hi All!

I would like to follow up on this thread. I have also tried to implement a kind of IoT like monitoring with custom topology. Metrics are flowing in nicely and I can setup alerting on top of it. But it seems the entity relationship is not there. At least Davis did not correlate the related issues.

However, I am not sure what are the best practices and the best usage here:

1. Is there any OOTB visualization of these custom relationships? Similar to the smartscape? Or any other way to visualize the custom relationship between the entities?
2. Based on the documentation DavisAI correlates between the relationships. However, when I generates issues I don’t see any correlation.
3. Can you explain to me what is the best usage of these capabilities? Based on the doc I can build nice IoT stuff on top of the custom topology. Is this something which is often used with Dynatrace? Do you have any example project which you can show so that I can understand the possibilities here?

[Julius_Loman]

Hi @sandorbihary ,

1. Not at the moment, it's not visible in the SmartScape as you already know. Not sure if there a new "smartscape" app in the works for the Dynatrace platform.
2. Based on my knowledge it does it only if there are certain relationship types between the entities - at least it works this way if you want to connect the custom topology with builtin entites.  @wolfgang_beer is there any public documentation on how does the root cause analysis works in detail, which entity types will Davis pick up and what are the required relationships?
3. The best usage is actually to extend the topolology and have your devices which don't fit into the builtin model monitored by Dynatrace.. You will probably create some Unified Analysis Screens which will show you data from your IoT devices also in relation. Then you can also use the Davis causal correlation analysis on them which I personally find super powerful and exciting during any problem investigation.

[wolfgang_beer]

1.) Smartscape was never updated to also show the new topology types, mainly because smartscape view was restricted to a very static layer model that does not fit well with completely custom topology types. In Grail I would expect that we show all entity types in a new smartscape visu.

2.) Davis currently just follows the custom runs_on relationships. The others are ignored, except as you said if you trigger the causal correlation analysis, there we take all the relationships and entities that are used and defined on the same page. We will of course add all other relationships in the Grail Davis analyzer once we are ready.

[Julius_Loman]

It would really make sense for Davis to consider other relations if they are configured so (maybe a flag on the relationship definition?). This would improve coverage of root cause analysis on custom topologies which is currently limited.

[wolfgang_beer]

Sure sure, there is no discussion about that. We plan to make it configurable with custom root-cause checks and traversal logic. Deployable through app definitions. At least thats the plan. Lets see how fast we can deliver that 🙂

[david_schnorr]

Stumbled upon this conversation today as I was searching for info on custom topology and Davis. Curious if there have been any updates or enhancements to the topology model and relationships to support problem root cause analysis? With the continued expansion of the extension 2 framework we see several relationship types are being set by these extensions. Additionally we are creating our own types. I am looking for some guidance on what we can expect from problem event/metric correlation and problem root cause analysis for custom entity types based on the relationship types used. Will custom all custom entity types and all relationship types be traversed and analyzed?

[wolfgang_beer]

Currently we are finishing the Davis Problems UI part with some significant enhancements. After this we will start to modify the Root-Cause engine to incorporate your additonal relationships and offer more configuration possibilities in terms of merge and split rules etc. We already started in that direction with a smaller feature which already considers network ALBs and to show root causes for those cloud load balancers.

Best greetings,

Wolfgang