Provider of automated application performance management (APM) solutions for microservices, Instana, has launched the Instana Context Guide, providing GUI-based access to the company's underlying system model called the Dynamic Graph.
Instana's solution discovers application service components and application infrastructure, including cloud infrastructure such as Azure, orchestration infrastructure like Kubernetes and Docker, application services and DevOps processes. Instana deploys monitoring sensors for each part of the application technology stack and traces application requests, without requiring human configuration or application restarts. The solution detects application and infrastructure changes, adjusts its models and visualises the changes and impacts to performance.
Part of that automation is enabled through the Dynamic Graph, an uber-model that includes dependencies, individual infrastructure health profiles, configuration information and performance information, updated as the system changes. The release of Context Guide means that users can access the dynamic graph for themselves and navigate across the application and infrastructure visualisations.
The Dynamic Graph is a component of Instana's automated and AI-powered features and is an inventory of individual entities, configuration data, performance metrics, dependencies and change logs. It's a model of an application that understands the physical and logical dependencies of components. Components are the piece parts of an application, like Host, OS, JVM, Cassandra Node or MySQL.
The graph also includes logical components like traces, applications, services, clusters or tablespaces. This provides situational context about services, relationships between services and the overall application.
InfoQ spoke to Chris Farrell, technical director and APM strategist at Instana, about the release:
InfoQ: How does Instana discover the application service and infrastructure components?
Chris Farrell: Instana has a single agent that is deployed as a process to a host, or as a Docker container on a Docker host, or as a DaemonSet on Kubernetes. The Instana agent automatically and continuously looks for known processes and technology signatures. Once a monitor-able technology is identified, the Instana agent downloads the appropriate sensor (technology specific monitoring code), automatically attaches to that technology, and begins monitoring without requiring any further configuration.
InfoQ: How does it deploy the monitoring sensors and how can a user be sure sensors are deployed everywhere they are needed?
Farrell: Instana sensors are stored in a remote repository that is accessible to the Instana agent. Once the agent identifies a supported technology, the appropriate sensor is pulled from the repository, configured, and applied automatically.
InfoQ: How does sensor deployment not require an application restart?
Farrell: Instana sensors are used to monitor metrics from infrastructure components. Many technologies, such as Docker containers, allow for dynamic attach and Instana utilises standard interfaces wherever possible. When it comes to tracing requests across services, there is no need to reboot services if they are written in Java, Python, or PHP. For all other supported language runtimes a reboot is required. 95% of Instana's supported technologies do not require any configuration changes or reboots.
InfoQ: How does it respond when application service and infrastructure components change or are removed?
Farrell: Changes are detected by the sensors (and agent) in real-time, and are noted in the Dynamic Graph, which feeds all other systems (dashboards, visualisations, Context Guide, incidents, etc.). Time of updates, instantiation, removal, etc. are all captured and stored - so that it's possible to play back the application progression at a later date.
InfoQ: What is meant by 'uber-model'?
Farrell: The Dynamic Graph contains configuration data, dependencies, performance information and health indicators. It drives the other components of Instana, from mapping and visualisation to tracing and automated root cause analysis. It is the overlying model, hence the phrase uber-model.
InfoQ: Prior to this release, how did users visualise what was happening across their microservices using Instana?
Farrell: Instana always included maps of service interaction and infrastructure. On the service maps, users could see all services or just services associated with specific applications or processes. When examining a specific service, there were ways to examine the infrastructure components. Before Instana released Context Guide, users were limited to interacting with the visualisations that Instana provided for navigating across component dependencies. Context Guide enables users to fully interact with the Dynamic Graph (all dependencies).
InfoQ: What is the use case for developers for these new features?
Farrell: For developers, understanding how their application or services were deployed to production is critical for verification. For example, when an application or service is deployed to production, it's possible that certain configuration artefacts were not updated properly and the production environment could be interacting with non-production services. This could have performance and stability impacts, or worse, legal ramifications. Context Guide makes it fast and easy for developers to verify that their applications or services have been deployed properly. Another common use case for developers is for production support of their applications and services. Often, only the most difficult production issues get escalated to developers. When this happens, developers need a way to quickly orient to the production deployment to begin their troubleshooting efforts. Context Guide provides immediate orientation in a few clicks and assists with the troubleshooting process by bringing KPIs of dependent components and services to the forefront.
InfoQ: How might using these new features impact the way a (cloud) architect works?
Farrell: One of the great things about the ability to navigate the Graph is that architects have the ability to see how deployment both fits their theoretical models and where it doesn't, since it's based 100% in actual interactions. Whether by the nature of the technologies used or the way that developers implemented them, any differences will be easy to identify, isolate and either accept or take steps to correct.
InfoQ: How might Dynamic Graph and Context Guide help teams to measure the value of the new features they deploy?
Farrell: One of the features of Instana has always been the ability to provide immediate feedback upon any deployment. That ability is born from the existence of the Dynamic Graph and that fact that the agents and sensors identify changes in seconds. That capability remains; what the Context Guide does is now allow the team to focus on the newly updated service and see, on screen, the upstream impacts of that particular service. In other words, they instantly see which applications are impacted - positively or negatively - with the latest update.
You can learn more about Instana and Context Guide here.