Application perspectives

The AP Creation Wizard is an interactive, simple way to create an AP. It has three steps:

1. Select a blueprint from the common use cases.
2. Specify the application’s model by selecting the tags and values to identify the services or endpoints to include.
3. Provide the final details to finish the creation.

Each of these steps is briefly discussed next with accompanying screenshots. At any time, you can switch to the advanced mode by selecting the Switch to Advanced Mode button.

The screen for the first step is shown as follows. The AP creation begins by selecting one of the blueprints:

• Services or Endpoints: The simplest way to construct an AP is by selecting the collection of services or endpoints directly.
• A Critical User Journey: Similar to the preceding blueprint but with defaults for use with the SLI / SLO capability. This blueprint will be enhanced in the future for deeper SLI / SLO integration.
• Environment or Region: Selecting the services based on an environment (for example, production or staging that may be described by the agent.zone tag) or region (for example, US East).
• An Important Customer or Tenant: By using custom tags or HTTP parameter information, an AP can be constructed for your important customer or tenant.
• Kubernetes or Container: A platform-oriented way to specify the collection of services that form an AP.
• Request Attributes: An AP based on request attributes (for example, HTTP headers, query parameters).
• Technology: A group of services based on a technology (for example, MySQL, all databases) or application name.
• Custom Tags: You can add your own metadata as a custom tag via the SDK and the custom tag data specifies the collection of services or endpoints.

After selecting a blueprint, the recipe card is updated to show information about the model and tips for creating the AP. Selecting “Next” moves to the second step.

The second step has two criteria for specifying what data sources form the AP. The first criterion is the tag selection menu and the Query Builder. The second criterion is the selection of the downstream services to include. After any criteria selection is made or updated, the preview window shows the selected services based on data from the last hour. This allows you to interactively fine-tune your selection by making updates and immediately seeing the effect. These two criteria do need much explanation.

The Query Builder is similar to the one presented in Unbounded Analytics. Each blueprint has a curated set of menus and associated tags specific to that menu. This streamlines the selection of a tag. You can use several filters to specify an application perspective. The preview window lists all the services that match the filters.

Downstream services are the other criteria to update the preview window because it determines what additional information is collected as part of the AP. There are three options:

• No downstream services: Only the selected services from the filters are included (called the core set). This is useful when you treat the services as opaque. An example is the services that represent 3rd-party APIs.
• Immediate downstream database and messaging services: Include the core set of services from the filters and then expand this core set to include the database and messaging services that the core set directly interacts with. This is useful if you are want to monitor a set of services and their direct dependencies (for example, a development team responsible for several micro-services).
• All downstream services: It effortlessly and automatically includes all the services that form the entire end-to-end dependency chain of the core set of services. This is useful if the AP will be used for troubleshooting.

Only one of these options can be selected at a time.

The figure as follows is an example of creating an AP based on a Kubernetes namespace. “All downstream services” is selected so this AP can provide both the opaque view to monitor a client’s experience and the end-to-end view for troubleshooting.

If the Instana user is a member of a group with the Contributor role, new APs can be created only within the predefined scope of the Contribution filter. For more information on setting the Contribution filter, see Applications. If the Instana user is a member of multiple groups with the Contributor role, the Select contribution filter list is displayed. Select a filter from the list.

Clicking “Next” brings you to the third step.

The third and final step is shown as follows where the name of the AP is added and the default dashboard view is selected. The default dashboard view can be changed at any time with a simple menu selection. The preview window information is also carried along to show the services that were selected. This is shown in the figure as follows.

The “Services or Endpoints” blueprint can be used to select multiple items and there are some features that are worth highlighting.

In the figure as follows, the user has selected three different services from the “Services” menu item. These services are joined by the Boolean OR operator instead of the AND operator so all the services are included in the AP.

To select multiple endpoints, you first select a service and can then select multiple endpoints of that service. In the figure as follows where three endpoints are selected in the cart service.

At any point, you can switch from the simple wizard mode to the advanced mode by using the button. In the Step 2 example, selecting the advanced mode presents the screen that is shown as follows. All the data that you previously entered is carried forward to this view. The reverse is also true; this data is not lost if you select “Simple Mode”.

If the Instana user is a member of a group with the Contributor role, new APs can be created only within the predefined scope of the Contribution filter. For more information on setting the Contribution filter, see Applications. If the Instana user is a member of multiple groups with the Contributor role, the Select contribution filter list is displayed. Select a filter from the list.

Existing application perspectives can be updated or deleted. Note that once an application perspective is updated, the new configuration only applies to new incoming calls after the change. Calls and services that were included in the application before the change are not affected.

1. On the sidebar, click Applications and then select your application perspective.
2. Select the Configuration tab.

A maximum of 50 application perspectives per call is supported. This limitation applies separately to "source applications" and "destination applications". Therefore, a call can be associated with up to 50 source application perspectives and 50 destination application perspectives. If a call exceeds this limit, only the first 50 application perspectives of each type are associated with the call.

If a call is linked to a high number of application perspectives, it usually indicates an issue with misconfigured applications. A common misconfiguration is unintentionally using the OR logical operator instead of AND in tag filter expressions.

For example, if you create an application perspective with the filter service.name = "service-a" OR agent.zone = "prod", it matches all calls to service-a in any zone, and all calls to any service in the prod zone. This configuration might unintentionally include many more services than intended.

A more targeted approach is to use service.name = "service-a" AND agent.zone = "prod", if you want to monitor only service-a running in the prod zone.

Regularly review your application perspective configurations to make sure that they are properly scoped and not overly broad. Misconfigured or broad perspectives can lead to performance issues and confusing monitoring results.