The term microservice means different things to different people. For some, the microservice corresponds with the "boxes" drawn on the whiteboard when talking about system architecture. Others refer to a more formal definition that describes a network-addressable endpoint with functionality determined by its external-facing API that can be developed, deployed, and operated independently from other microservices in the system. Still others base their understanding on the microservice concept provided by their development platform, like the App Engine services or the Anthos Service Mesh service.

Our goal is not to force a definition of microservice upon you. Instead, we want to help you monitor your systems at scale during your digital transformation by providing service-oriented monitoring tools to support you and your architecture. We want to work with you to adopt best practices for monitoring systems without changing a single line of code.

To do this, Cloud Monitoring auto-detects microservices when it can, provides a guided experience for defining Google Kubernetes Engine-based microservices, and offers a fully custom solution for maximum flexibility.

Auto-discovered microservices

Some modern development frameworks offer a strongly opinionated concept of a microservice. In architectures that make use of such a framework, Cloud Monitoring can automatically detect when services are deployed, updated, or deleted. It accomplishes this through constant analysis of the metadata stream produced by a project.

Cloud Monitoring can automatically detect microservices built using the following development frameworks:

  • App Engine: App Engine has a strong notion of microservice, called an App Engine service (and formerly a module). Each service is distinguished by its own app.yaml configuration file.

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

  • Open Source Istio on Google Kubernetes Engine: GKE provides support for Open Source (OSS) Istio using the "add-on" feature of GKE. Using the GKE add-on, users benefit from managed installation and upgrade of Istio components. As with Anthos Service Mesh, a OSS Istio service corresponds directly with a GKE service.

Dashboards for auto-discovered microservices

A service dashboard is automatically created for all auto-discovered microservices. The dashboard contains the metadata details of the service, the alert timeline, the SLO status, and logs related to the service. Each of these components is described in more detail in Using microservice dashboards.

Service dashboard for auto-discovered microservices.

GKE-based microservices

GKE, and Kubernetes on which it is based, is a highly flexible container orchestration system for deploying, scaling, and managing containerized applications. Based on research of a number of advanced Kubernetes users, there is no single notion of microservice on which the community agrees. Some users base their microservices on the Kubernetes namespaces; others use a workload, like a replica set, to correspond to a microservice.

Note that users have developed a variety of patterns for using Kubernetes and a microservice may, but not always, correspond to a "Kubernetes service".

Because of the variety of ways users manage applications on Kubernetes, Cloud Monitoring can't automatically detect GKE-based microservices. Instead, we offer a guided approach to help users identify their microservices. To begin, click the link labeled Define service.

You can define a GKE service from the Services Overview dashboard.

The sliding tray shows a list of all of the GKE entities in your cluster, from namespaces all the way down to pods. It also shows the metadata labels to distinguish between entities with similar names. Use the filter bar to help you find the entity that corresponds to your microservice. Select the entity and provide a name, or use the default name provided.

To define a GKE service, select an entity from the list.

You have now identified a GKE-based microservice which can be used with the service-oriented monitoring features. The console shows the operation succeeded by displaying the details of the newly-created service. It also provides links to some possible next steps: learning more about best practices for service-oriented monitoring, creating your first SLO, or viewing the service dashboard.

After you create a service, you can configure SLOs and view a dashboard for
the service.

Dashboards for GKE-based microservices

A service dashboard is automatically created for each GKE-based microservice that is defined. As with dashboards for auto-discovered services, these dashboards contain the metadata details, an alert timeline, SLO summary, and related logs. Additionally, the dashboard contains a set of metrics for the service where different metric groupings can be selected for display. The bottom of the dashboard provides a summary with links of the pods comprising the service. Each of these components is described in more detail in Using microservice dashboards.

A service dashboard is created for your newly created GKE service.

Defining a GKE-based service (API)

GKE-based microservices can also be defined by using the SLO API, part of the Cloud Monitoring API. These services are represented in the API as a Custom service type with a Telemetry.resourceName value that identifies a GKE entity.

To create a service programmatically, post a configuration like the following to the services.create method:

  "displayName": "hello-world-microservice",
  "custom": {},
  "telemetry": {

More generically, the form of the resourceName field is "//container.googleapis.com/projects/PROJECT_ID/zones/ZONE/clusters/CLUSTER_NAME/k8s/namespaces/NAMESPACE_NAME/ENTITY_TYPE/ENTITY_NAME"

For more information managing services programmatically, see Using the API.

Creating custom microservices (API}

In the SLO API, the Custom service type can also be used to create a REST container to parent a collection of SLOs. This can be useful when defining SLOs on a service type that is not currently supported or on business metrics that do not naturally correspond to a microservice.

To create such a service programmatically, post a configuration like the following to the services.create method:

  "displayName": "hello-world-service",
  "custom": {}

For more information managing services programmatically, see Using the API.