This document introduces microservices and describes the types of microservicessupported by Cloud Monitoring.

The termmicroservice means different things to different people. For some,the microservice corresponds with the "boxes" drawn on the whiteboard whentalking about system architecture. Others refer to a more formaldefinition that describes a network-addressable endpoint with functionality determinedby its external-facing API that can be developed, deployed, and operatedindependently from other microservices in the system. Still others base theirunderstanding on the microservice concept provided by their developmentplatform, like theApp Engine services or theCloud Service Mesh service.

Our goal is not to force a definition ofmicroservice upon you. Instead, wewant to help you monitor your systems at scale during your digitaltransformation by providing service-oriented monitoring tools to support youand your architecture. We want to work with you to adopt best practices formonitoring systems without changing a single line of code.

To help you monitor your microservices, Cloud Monitoringdoes the following:

• Auto-detects microservices when possible
• Provides a guided experience for defining Google Kubernetes Engine- andCloud Run-based microservices
• Offers a fully custom solution for maximum flexibility

Auto-discovered microservices

Some modern development frameworks offer opinionated concepts ofa microservice. In architectures that use such frameworks,Cloud Monitoring automatically detects when services are deployed,updated, or deleted. Monitoring accomplishes this detectionthrough constant analysis of the metadata stream produced by a project.

Cloud Monitoring can automatically detect microservices built usingthe following development frameworks:

• App Engine: App Engine has a strong notion of microservice,called an App Engine service (and formerly amodule). Each serviceis distinguished by its ownapp.yaml configuration file.

• Cloud Service Mesh: Cloud Monitoring supports service meshesbuilt atop a single GKE cluster. In this configuration,a Cloud Service Mesh service corresponds directly to aGKE service. All Cloud Service Mesh services,both user-managed and system-managed, are automatically detected.

Dashboards for auto-discovered microservices

A service dashboard is automatically created for all auto-discoveredmicroservices. The dashboard contains the metadata details of the service,the alert timeline, the status of your service-level objectives (SLOs), andlogs related to the service. Each of these components is described inmore detail inUsing microservice dashboards.

Note: The alert timeline and SLO list will be empty since no SLOs or SLO alerts have been defined. To get the most out of your service dashboard, create SLOsand set alerts on them as described inCreating an SLO.

GKE, Cloud Run and custom services

Note: In Cloud Monitoring, aservice is a construct that you canassociate with SLOs and alerting policies. Several of the resourcesfor which you might create Monitoring services are alsoreferred to asservices, but with different meanings, likeGKEservices orCloud Runservices.

Cloud Monitoring can identifypotential orcandidate servicesfor the following types:

• GKE namespaces
• GKE services
• GKE workloads
• Cloud Run services

However, there may be many such candidates, and you don't necessarilywant to create SLOs on all of them. Monitoring creates alist of candidate services, and you identify the services you wantto treat as Monitoring services by selecting them from thelist. Monitoring then creates theservice infrastructure for you.

When no existing service type accommodates an application for which youwant to create SLOs, you can define a custom service.

For more information about identifying candidate services and creating customservices, seeDefining a microservice.