This is the new Smartscape model, containing model definitions for entities that are stored in Smartscape on Grail. All models, describing different entities are organized by domain in subfolders:
experimental A collection of additional metadata information imported to Dynatrace.
OperatorVersion:v0.9.0; cluster-name:ext-demo1
dt.smartscape_source.sender
string
experimental Indicates the source agent that created the Smartscape node. Possible values include OS agent, z/OS agent, or technology-specific code module agents running standalone.
dynatrace_codemodule
host.additional_system_info
record
experimental Additional system information. Some attributes here are only available on certain systems (e.g. system.lpar exists only on AIX). Several attributes are numbered. E.g. attributes starting with system.processor_. will have the underscore programatically replaced with an index like [12], starting from [0]. Note that in these examples, a '_' is replaced with '[x]', where x is a number starting from 0.
dt.smartscape_source.sender MUST be one of the following:
Value
Description
dynatrace_codemodule
An agent with a particular technology running as a standalone.
dynatrace_osagent
OS agent
dynatrace_zagent
z/OS agent
Relationship types
Edge type
Description
belongs_to
stable This is similar to an aggregation in UML. It is a many-to-many relationship without existential properties (the destination is not composed of the sources).
calls
stable Defines a "horizontal" relationship between two entities that "call" each other. The "calls" relation does not imply a parent/child or other strong structural relation but rather a dynamic communication association. Examples: Typical examples include services calling other services, but also services calling databases, queue brokers, or other infrastructure entities.
is_attached_to
stable Is (typically) exclusively attached to the instance (1-many)
is_part_of
stable Defines if the instance is part of a cluster, similar to a composition in UML. The source (child) cannot exist without the destination (parent).
runs_on
stable Defines a "vertical" relation of an entity running on some other entity. It does not imply any composition or aggregation but only a looser association between the entities. One entity can run on multiple other entities. Examples: Service running on a POD, a CONTAINER or a HOST.
routes_to
stable Define network route to the instance Examples: EC2 route table routes to EC2 NAT Gateway EC2 VPC Peering Connection routes to VPC
contains
stable Relationship field that contains all contains-relationships as nested fields. Opposite direction: belongs_to
instance_of
stable Relationship field that contains all instance_of-relationships as nested fields. Opposite direction: instantiates
balanced_by
stable Relationship field that contains all balanced_by-relationships as nested fields. Opposite direction: balances
balances
stable Relationship field that contains all balances-relationships as nested fields. Opposite direction: balanced_by
uses
stable Similar to is_attached_to but in the opposite direction. Examples: EC2 Instance uses DHCP options, Auto Scaling Group uses EC2 Launch Template
updates
experimental Similar to uses but with a stronger connotation where the source actively updates or modifies the target. It implies that the source has some level of control or influence over the target. Examples: A synthetic monitor updates credentials in a credential vault entry.
is_assigned_to
experimental Defines assignment relationship, where the source is assigned to the destination. Similar to is_attached_to, but introduced to preserve naming consistency Examples: A synthetic monitor is assigned to a frontend.
monitors
experimental Defines monitoring relationship, where the source monitors the destination. Examples: A synthetic monitor monitors a frontend. A synthetic monitor or OneAgent monitors a host.
sees
experimental Defines a visibility relationship where the source configuration has discovered the destination entity but does not actively monitor it. Used alongside monitors to distinguish projects that are visible to a DA monitoring configuration from those that are actively monitored. Enables the UI to show which configuration sees or monitors a given project and to detect overlaps across configurations. Applies to static edges only; dynamic edges are out of scope. Examples: A DA monitoring configuration sees project.
same_as
experimental Defines an equivalence relationship. Examples: A database instance is the same as a host process.
Network identification fields
Attribute
Type
Description
Examples
interface_config
record[]
experimental Network interface configuration, including IP address and network prefix length