TABLE OF CONTENTS
- Working with Application Perspectives
Application Perspectives are a unique core capability of Instana. To learn about the concept, head over the Core Concepts > Application Perspectives
An Application Perspective (AP) is a power tool for monitoring, alerting, and analysis of a microservice environment. Each AP auto-generates a feature rich monitoring dashboard for the golden signals and more (see figure below). It organizes a team so they stay focused on the services they are interested in and aren’t distracted. Alerts, errors, and logs are scoped to an AP to focus the troubleshooting. From a security perspective, an organization can use an AP to limit visibility to infrastructure and services.
An Application Perspectives achieves this by enabling you to dynamically scope the visibility to “just the right” size to meet your needs, such as:
- by specifying a sub-set of services along with their dependencies;
- by zone or cluster;
- by technology;
- by business transaction or user journey;
- by deployment engine;
- by version or release;
- or any combination.
An AP helps you to apply the proven problem-solving algorithm of “divide and conquer.”
Some recent blogs which are recommended reading are:
- Taming the Complexity of Microservices Using Application Perspectives
- How Developers Can Tame Microservices Sprawl
The Application Perspective is a unique capability of Instana. An AP creation wizard is available for new users to easily create simple and frequently used types of APs. An advanced screen is available if you are familiar or proficient with Instana or you need to create a sophisticated AP. It is very easy to switch between these two modes without data loss.
There are two ways to launch the creation of an AP.
- On the sidebar, click Applications -> Create Application Perspective.
- From the Instana dashboard, click New Application Perspective on the Applications tile.
Either path takes you to the AP creation screen which is explained next.
The AP Creation Wizard is an interactive, simple way to create an AP. It has three steps:
- Select a blueprint from the common use cases.
- Specify the application’s model by selecting the tags and values to identify the services or endpoints to include.
- 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 button in the top right that says “Switch to Advanced Mode.”
The screen for the first step is shown below. The AP creation begins by selecting one of the several blueprints on the left side:
- 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 blueprint above 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 (e.g., production or staging that may be described by the
agent.zonetag) or region (eg. US East).
- An Important Customer or Tenant: By leveraging 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 (eg. HTTP headers, query parameters).
- Technology: A group of services based on a technology (eg. MySQL, all databases) or application name.
- Custom Tags: You can add your own meta-data 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 on the right updates 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 criteria is the tag selection filter menu. The second criteria is the selection of the downstream services to include. After any criteria selection is made or updated, the preview panel 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 a little more explanation.
The tag selection filter menu 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 panel will list all of the services that match the filters.
Downstream services is the other criteria to update the preview panel 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 (call this the core set). This is useful when you treat the services as opaque. An example would be 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 (e.g., 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 below 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.
Clicking “Next” brings you to the third step.
The third and final step is shown below 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 panel information is also carried along to show the services that were selected. This is shown in the figure below.
The “Services or Endpoints” blueprint can be used to select multiple items and there are some features that are worth highlighting.
In the figure below, 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. This is a simplification from the Advanced Mode where you would need to manually change the “AND” operator to the “OR” operator for the same effect.
To select multiple endpoints you first select a service and can then select multiple endpoints of that service. At the moment, the endpoint selection is limited to a single service. This is shown in the figure below where three endpoints are selected.
All the data that is needed for an AP is entered in a single screen with the Advanced AP creation view. The steps within this view are:
- Enter a name for your application perspective.
- To define your application perspective using tags, click Add tag.
For tags to conjoin, choose between the AND or OR operator. When using a mix of AND and OR conjunctions, AND conjunctions have the highest priority and are evaluated first. For example, the tag definitions tag.A AND tag.B OR tag.c AND tag.d is interpreted and processed as (tag.A AND tag.B) OR (tag.c AND tag.d).
Each call that matches the filters, including calls to any database or messaging services that are invoked within the application, is associated with this application perspective.
There is also an option to apply filters and group by the source or destination of a call.
endpoint.name tags, along with the infrastructure entity tags such as
host.name can be applied to both the source and the destination of a call. By default, it's applied to the destination and it can be modified by using the edit filter dialog. An example for combining source and destination is for an application that groups calls which are issued from the
agent.zone prod towards the
- To include all the services that transitively fall downstream of those matched by the tags you have specified, select Include All Downstream Services. Select No Downstream Services if only the filtered services are all to consider. Select Immediate downstream database and messaging services if the database or messaging services directly communicating with the selected services should be included in the AP.
- Select the default dashboard view:
Inbound calls: Inbound calls are calls initiated from outside the application and where the destination service is part of the selected application perspective.
All calls: Results and metrics for not only calls at the application perspective boundary, but also those occurring within the application perspective.
By default, various dashboards such as the Summary tab, only show numbers for "Inbound Calls". Wherever the Inbound or All Calls selector is available on a dashboard, the perspective can be switched to All Calls. When selecting services and endpoints within an application perspective, the boundary setting is inherited.
At any point you can switch from the simple wizard mode to the advanced mode using the button. In the Step 2 example above, selecting the advanced mode would present the screen shown below. All of the data that was previously entered is carried forward to this view. The reverse is also true -- if you were to select “Simple Mode” this data would not be lost either.
Newly created application perspectives can be updated or deleted. Please note that once an application is deleted, it still appears in the applications list, as long as it existed during the selected time window.
- On the sidebar, click Applications and then select your application perspective.
- Select the Configuration tab.