Instana’s Enterprise Observability Platform provides a vast range of application and microservice metrics, events, traces, profiles, and application log information with the context needed to manage Cloud-native environments. It’s an abundance of riches.
When you have that much information, it can be challenging to quickly discover the specific information you want to find. The more complex the application is, the harder it is for individuals (or teams) to find the data most relevant to their specific responsibilities.
That’s just one of the monitoring problems addressed by Instana’s Application Perspectives. An application perspective is a filtered set of services and endpoints defined by a shared context:
- Services created by a specific developer
- Components created / provided by a specific team
- Components and Services associated with a specific URL or application
- etc. etc. etc.
Application Perspectives allow any user, from DevOps to Developer, to organize information into the exact visualizations and context they need to monitor, examine and optimize the applications and/or services they’re responsible for. Active application perspectives are applied across every aspect of the Enterprise Observability Platform – creating a personalization across Instana’s entire platform – service and infrastructure maps, dashboards, alerts, traces, profiles, incidents, even analytics.
Out-of-the-box Application Perspectives templates provide quick and easy ways to create your personal view in one of the standard ways that make sense to your task load. The templates enable you to select the type of perspective you want to create along with the means to select the tags for the to-be-monitored application information.
Role Specific APM / Observability Dashboards
One interesting way to use Application Perspectives is to create role-specific perspectives, allowing different types of application stakeholders to focus in on things most relevant to them. Each member gets their own view into the part of the Application or Service that is important to them or that they’re responsible for. This extremely effective information presentation means they won’t have to wade through a multitude of data, maps and/or dashboards the don’t concern them.
Built-in Views of Application Perspectives
There are two built-in views of Application Perspectives that can help individuals and/or teams better understand how the pieces they care about are operating:
- A monitoring view for a group of services or endpoints
- Viewing the end-to-end call flows discovered at run time
These two views are controlled by the “Downstream Services” and the “Dashboard View” option specified in the Application Perspective setup. Downstream services determine what additional data should be collected and Dashboard View determines the default dashboard view. Users can easily transition from the monitoring view to the end-to-end view at any time from the menu.
Creating Application Perspectives, Step-by-Step
To create an Application Perspective, start at the side bar menu and select Applications.
On the application screen, where previously defined Application Perspectives are displayed in a multi-page table, navigate to the bottom right corner and select the Add button.
Then select the New Application Perspective button to open the Application Perspective creation page, and select a template.
The Application Perspective menu presents the wide range of templates (see above) for rapidly creating Perspectives for different use cases. These templates were created for common use cases that many of our customers implement and have been continuously improved by feedback from them. There’s also a selection for Custom Tags which lets you assign the information that Instana captures in any way that meets your requirements.
For this step-by-step explainer, we’ve selected the Services or Endpoints template for our Application Perspective. An explanation of the typical uses for all the Application Perspective templates is in the table below.
| Pre-Built Templates | ||
| Template Type | Description | Typical User |
| Services or Endpoints | Services or endpoints are often an application that a specific team is responsible for, or which provides a single function. | DevOps, Operations, SRE, Developer, QA, Support, Business owner |
| A critical user journey | A user journey typically consists of a set of interactions a user has to achieve an end result – such as for a business use case or business transaction | DevOps, Operations, SRE, Business owner |
| Environment or Region | Models applications using environment information such as cloud information, zone region, host name or ID | DevOps, Operations, SRE, QA, Business owner |
| An important customer or tenant | Important customers or tenants can have Application Perspective dashboards by using an HTTP parameter to identify a customer or tenant or with manual instrumentation using the tracing SDK | DevOps, Operations, SRE, QA, Business owner |
| Kubernetes or Container | Group services based on a Namespace, container or image name, platform service names, deployment information or labels. | DevOps, Operations, SRE, Developer |
| Request Attributes | Model different environments using HTTP headers, HTTP return code status, portions of a URL, request parameters, or a RPC method or object. | DevOps, Operations, SRE, Developer, QA, Support |
| Technology | Model a grouping by technology or application type such as database type or schema, Java application name or scripting application name | Operations, SRE, Developer, QA, Support, Business owner |
| Custom Tags | Model your own data from the SDK, platform, etc. using the HTTP protocol, Instana agent, AWS, data attached to a call, and Kubernetes or Container labels. | DevOps, Developer, QA |
After we’ve selected the Services or Endpoints template, we’re guided to the screen where we can select the information and attributes that we want to monitor.
For our use case, we’ve selected to monitor 2 Kubernetes Namespaces, a Zone and a Service name. We’ve logically ORed them together to express how we want those measurements aggregated.
After we’ve specified the measurements and services that we want to observe, we’re then asked to provide a name for our Application Perspective and also declare the type of calls that we want to monitor.
After a few moments and in order to aggregate enough information for an adequate visual display, we see the Application Perspective we built. That’s it, your Application Perspective is now active. If you would like to see other indicators, you can select them from the menu directly above the summary displays. Or, if we want to change your query settings to something else, we can do so by selecting the Configuration menu selection.
When you’re done with your newly created Application Perspective and leave the display, you can return to it from the Applications main page (see below).
Instana Application Perspectives lets you organize the vast amount of rich Enterprise Observability information generated by Instana into display elements configured EXACTLY as you want them. It also lets you configure Application Perspectives for additional stakeholders and views. All to get to the root cause of any issue rapidly and show the stakeholder how well the application(s) and service(s) are performing.
Instana Application Perspectives simplifies monitoring of complex, highly distributed modern cloud-native applications. The key uses, structure, and definition of an Application Perspective have been explained above. You are now an Application Perspective Ninja who can show your enterprise stakeholders – developers, SREs, DevOps, IT operations, and Line of Business – that THEY can get a personalized view of your environment, allowing them to use Observability to help them do their job.
