Applications are IT’s reflection of the business processes a company is automating. Applications are collections of Services which essentially model and deliver specific business processes. A management tool would presumably do quite well then to be able to specifically identify, connect to and model a “Service”. This blog introduces a new capability which is our first step towards service management.
Services are constructed and delivered by their interactions/requests to your microservices. The challenge of monitoring these types of applications is that the structure/design/architecture of the microservices (and thus the Services) are constantly evolving due to your own continuous integration and delivery (CI/CD) processes. Let’s remember, the purpose of monitoring, especially APM, is to help you manage quality of service and subsequently support, deliver and improve the desired business outcome and customer experience.
Instana is very capable at monitoring microservices. Instana automatically detects your microservices, automatically discovers and tracks their changes and brings to your attention any quality issues (Incidents) you should take action on. With the introduction of the Service Mapper capability, Instana now allows you to more precisely align (identify, define, name) and then manage your services.
Service Mapper enables you to define how Instana should discover your Services. All configuration is applied to the processing of the data in the Instana backend. There is no need to configure the agent at all. All settings are applied after about 30 seconds.
Services are discovered by analyzing Traces and grouping them. As soon as a Service is discovered Instana will analyze its health and inform you if something needs your attention. To help Instana better align to your architecture you can customize the Service detection. Please note that the data used to discover the Services are the Traces.
By default we recognize e.g. HTTP Services using the first request path segment –
/productsearch/hello would be mapped to the Service “productsearch“.
The detected Service in this example will be called “localhost:84/shop” because the rule gets the Hostname and Request Path and uses these values to detect the Service. If another request would be done on another server a new Service would be discovered.
If you would apply the above rule to the second span in the above example with the values
URL=/productsearch the Service would be named: 172.17.42.1/productsearch.
Following this simple approach, you inform Instana how it should discover your Services. All discovered Services are subsequently automatically monitored!