DX-APM Attribute Enhancements
Article ID: 274774
Updated On:
Products
Issue/Introduction
We requires that all agents to contain attribute decorator extension, which together with attributes extracted from agent identity (host name, process name & agent name), provides a rich eat of meta-data about agents and the relationships of those agents to our organizational structures and processes.
The enhancements are broadly grouped as follows:
1) Enable easy access to values of attribute(s) for an agent
2) Allow alert notifications to include values of attribute(s)
3) Allow selection of agents by attribute values
4) Add data source to record set of unique values of each attribute
Group 1 - Enable easy access to values of attribute(s) for an agent
Reason: enable teams to verify their decorated attributes are reported correctly and allow rapid access meta-data agents when triaging issues.
1.1 Add tab in right panel of ATC Metric View, similar to Metric Count. At present decorated attributes can be viewed via Agent card, Experience Card and Map View - though only the agent card route works for agents that do not report ‘experiences’ (i.e. Infrastructure agents, PerfMonCollector agents, and some in-process agents). Using Agent cards, it takes multiple clicks and scrolls to get to the relevant part of the isolation view.
1.2 Provide API to allow values of attribute(s) to be retrieved for specified agent(s). This may already be possible at least for attributes defined by rulesets, but documentation is unclear. It is even less clear if existing APIs work for attributes defined by attribute decorator extensions.
1.3 Allow DX-Dashboards to retrieve and display values of attribute(s) specified agents(s). DX-Dashboards and reports provide simpler access to non-APM specialists who need to consult/review attribute values than existing ATC or Enhancement 1.1 provide.
Group 2 - Allow alert notifications to include values of attribute(s)
Reason: dispatching alert notifications depending on the identity of the agent that reported the metric which crossed the alert threshold may be achieved by defining different channels for each destination. This would require a high and ever increasing number of channels. Best practice as advised by Broadcom is to minimise the number of channels. In addition, channel definition and configuration is a tenant admin function, so would require significant additional manual effort from the APM team, or would additional automation to be developed, tested and maintained. If dispatching is performed at the notification destination the destination must maintain the mapping from alerts, management modules or universes to specific final target for example queues and properties of INCs raised within SNOW so correctly populated SNOW INC can be raised when alert notifications are received. Incorporating values of attribute(s) within the notification would eliminate the code and configuration management required within destination to manage the notification mapping and place configuration close to the alert definitions to which it logically relates.
1.4 Enable values of specified attribute(s) to be included in webhook alert notification payload. This must allow both ‘decorated attributes’ and those defined via tenant attribute rules to be included in notification payload. This will also massively simplify development of alternative endpoints.
Group 3 - Allow selection of agents by attribute values
Reasons:
a) reduce duplication of regular expressions as such as the universe-defining regular expressions.
b) enable sets of agents with specific attribute value(s) to be located to target communications from APM team to specific subsets of user base or to allow comparisons between different agents monitoring similar or related technologies.
For these enhancements, the selection of agents returned must, in addition to meeting attribute restrictions, also be restricted by the user’s access rights, so only agents the user is permitted to view are returned.
3.1 Allow universe membership to be defined by selecting agent(s) having specific attributes values. At present universe membership may only be defined by regular expression to match agent identities (host name, process name, agent name) or by selecting specific agents explicitly. Given an agent naming convention all agents within any universe will have a specific value of one of the attributes extracted from agent identity via an attribute ruleset. Therefore an alternative to existing agent identity matching regular expressions would be to define universe membership as all those agents where specific attribute value matched a pattern.
3.2 Allow alternative form of management module and metric grouping ‘agent expressions' to select agents based on value(s) of specific attributes. For example 'agent expressions' for Management Modules and/or Metric Groupings related to POC universe could be expressed as ‘all agents with Example_AppName attribute value of POC’. If attribute specification could be combined either with another attribute specification or an agent identity regex specification, definition of universe subsets would be simpler and not required such complex derivations of universe-defining regular expressions. For example a subset could be all agents where attribute Example_AppName matches POC and attribute location matches data centre DC
3.3 Add decorated attributes to set of attributes upon which filter can be defined in ATC Metric View. At present only non-decorated attributes can be used. Decorated attributes would allow a project extensible set of filters to be defined thus making filters much more powerful for large universes.
3.4 Allow API calls to request set of agents with specified attribute value(s). This would permit automation to gather usage metrics related to specific universes or technologies that could for radiate such information to upper management to help justify DX-APM investments or be incorporated within systems to help triage of issues by locating ‘similar’ agents etc.
3.5 Allow DX-Dashboards to define Source Name Specifier based on attribute values. As with enhancement 3.2, this reduces duplication of complex universe or sub-universe defining regular expressions, It would enable generic dashboards to created allowing users to choose specific subsets of agents to focus on. For example a dashboard agent specifier could be of the form of 'All agents where Example-AppName attribute has value POC. Again as with enhancement 3.2, it should be possible to combine multiple attribute and/or agent identity matching specifications.
Group 4 - Add data source to record set of unique values of each attribute
Reason: enable creation of more generic dashboard whose focus can be changed at runtime by user selecting values of variables via ‘drop down’ choice lists in the dashboard UI.
4.1 DX-Dashboards should have data source containing set of values for each attribute. These known-value sets should exist for all attributes (both those defined by tenant’s Attribute Rulesets for which new values appear as rulesets extract values from new agent identifiers, and those defined by agents Attribute Decorator extension where new values appear as agents report sets of decorated attributes). Some consideration should be given to aging out old values (for example a project is decommissioned, so its agents longer report and thus project specific values are no longer extracted by tenant' Attributes Rulesets or from agent’s Attribute Decorator extensions), though until data is aged out even though new attribute values (or existing values are re-discovered) as agents are no longer connecting/reporting, the historical metrics from those agents remain and thus dashboards could still require ability to select such agents. As RBAC is incorporated into DX-Dashboards, it will be necessary to restrict set of attribute values to only those related to agents that are within universe(s) the current user has access to.
This enhancement would enable creation of generic dashboards where choice list presented to user would be based on currently valid attribute values (or subset of those) allowing user to focus dashboard contents by selecting from variable ‘drop downs’ and the selected values then being used to configure agent specifiers (either via Enhancement 3.5 or via existing agent identifier based Agent Specifier regular expressions). For example, if a DX-Dashboard variable value is a comma separated list of all universe names, user could select the universe dashboard would focus on. At present, to set value for such a variable , a query must be run against all agents to extract set of unique universe names from all agent identities. Such an ‘all agent’ query never completes when tenants have the high agent loads. The alternative available at present to hardwire the value of universe selector variable. However the hardwired value must be changed as set of universes (and thus possible values) changes. It would be impossible to refine this to only contain values related to agents the current user is able to view. What would be much more powerful is when the set of possible choices was based on specific attribute value-set (global and decorated) from the current tenant, restricted by current user’s access rights.
Environment
Release : SAAS
Resolution
Enhancement # F139078 has been created for current limitation.
For more details or an update contact Broadcom Support
Additional Information
Feedback
