This document is one part of a two-part series on extending Cloud Loggingand Cloud Monitoring to include on-premises infrastructure and apps.

• Log on-premises resources with BindPlane:Read about how Cloud Logging supports logging from on-premisesresources.
• Monitor on-premises resources with BindPlane (this document): Read about howCloud Monitoring supports monitoring of on-premises resources.

You might consider using Logging and Monitoringfor logging and monitoring of your on-premises resources for the followingreasons:

• You need a temporary solution as you move infrastructure toGoogle Cloud and you want to monitor your on-premisesresources until they're decommissioned.
• You might have a diverse computing environment with multiple clouds andon-premises resources.

In either case, with the Logging and MonitoringAPIs andBindPlane,you can gain visibility into your on-premises resources. This document isintended for DevOps practitioners, managers, and executives who are interestedin a monitoring strategy for resources in Google Cloud and their remainingon-premises infrastructure and apps.

Ingesting metrics with Monitoring

You can get metrics into Monitoring in the following two ways:

• Use BindPlane from observIQ to ingest metricsfrom your on-premises or other cloud sources.
• Use OpenCensus to write to the Cloud Monitoring API.

Using BindPlane to ingest metrics

The following diagram shows the architecture of how BindPlane collects metricsand then how these metrics are ingested into Monitoring.

observIQ offers several versions of BindPlane: BindPlane for Google, self-hosted,SaaS, and Enterprise. For more information about these versions, see theBindPlanesolutions page.

Advantages:

• Requires configuration, not instrumentation of your apps, which reducestime to implement.
• Included in the cost of usingMonitoring.
• Supported configuration by Monitoring product and support.
• Can extend to metrics not provided by the default configuration.

Disadvantages:

• Requires the use of the observIQ BindPlane agent to relay metrics toMonitoring, which can add complexity to the overall system.

This option is the recommended method because it requires the lowest amount ofeffort. This solution requires configuration rather than development.

Using OpenCensus to write to the Monitoring API

The following diagram shows the architecture of how OpenCensus collects metricsand how these metrics are ingested into Monitoring.

Using the Monitoring API directly means that you need to addinstrumentation code to your apps to send metrics directly to the API. You cando this directly byusing the Monitoring API to write metrics or by instrumenting your app with theMonitoring exporter for OpenCensus.OpenCensus is an open source project that defines a standard data structure fortraces and metrics. Using OpenCensus has the advantage of supporting multiplebackends, including Monitoring. Using OpenCensus also implementsall the low-level technical details of using the Monitoring API.

Advantages:

• Provides flexibility because the instrumentation required is easilyimplemented with the use of the OpenCensus Exporter

Disadvantages:

• Requires a separate solution for infrastructure metrics by writing acustom agent.
• Requires app instrumentation, which might mean higher cost to implement.
• Requires open source libraries.

This option isn't the recommended method because it requires the highest amountof effort and doesn't cover infrastructure metrics.

Using BindPlane

This document covers using BindPlane from observIQ to ingest metricsinto Monitoring. The BindPlane service works by defining a seriesof sources, ingesting those metrics, and then sending the metrics toMonitoring as the destination. BindPlane supportsagents that run onselect versions of Windows, Linux, and Kubernetes.

Sources, agents, destinations, and processors

BindPlane has the following features:

• Sources: Items that generatemetrics such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes(Amazon EKS), or Microsoft Azure Container Service.
• Agents: Lightweight processes that remotely monitor yourenvironment and forward metric data to BindPlane.
• Destinations: Services thatBindPlane forwards the metrics. In this case, thedestination is the process on BindPlane that uses theMonitoring API to write metrics to Monitoring.
• Processors: Configurationsthat can transform your data before it arrives at your destination. Thisincludes adding attributes, filtering, and converting logs to metrics.

For more detailed information about sources, agents, destinations, and processors,see theBindPlane QuickStart Guide.

Example use case

As an example, ExampleOrganization has resources deployed to Google Cloud,Microsoft Azure, and on-premises resources deployed by using vSphere. InGoogle Cloud, there is a GKE cluster and a demo appdeployed, which runs the company's website. In the Microsoft Azure environment,Azure Kubernetes Service (AKS) is running a set of microservices, providing aREST API endpoint to external developers. In the vSphere environment,MySQL, Oracle, and Microsoft SQL Server support several corporate apps.

With resources in each environment, ExampleOrganization wants to monitor eachcomponent regardless of where the component is deployed. Sending the metricsfrom each environment to Logging and Monitoring byusing BindPlane brings all the metrics into a single location for monitoring andalerting purposes.

Send metrics from BindPlane to Monitoring

After BindPlane is set up and begins sending metrics, those metrics are sent toyour Monitoring Workspace. You can then useMonitoring to view, configure, alert, and build dashboards fromthe time series like you can for any metrics or time series in Monitoring. Formore information, seeMetrics, time series, and resources.

Use metrics in Monitoring

In the previous example, BindPlane was configured to send metrics fromGoogle Cloud, Microsoft Azure, and on-premises sources. The following threemetrics appear in Monitoring:

• GKE cluster metrics
• AKS cluster metrics
• vSphere on-premises database metrics

GKE cluster metrics

If you have GKE clusters set up, the GKE cluster metricsappear in theKubernetes Clusters pageorKubernetes Workloads page.You can see multiple views of the Kubernetes componentsrunning in Monitoring. The metrics, logs, and configuration areavailable for each pod.

For details, seeView observability metrics.

AKS cluster metrics

In the sameMonitoring environment, metrics for AKS are collected. The metrics appear inMonitoring and can be used for any purposes inMonitoring including dashboards, alerting, and the MetricsExplorer.

TheMetrics Explorer page provides a way to find, filter,and build charts from metrics. Note that the metrics sent in by BindPlane havetheworkload.googleapis.com/THIRD_PARTY_APP_NAMEprefix for the metric name.

The Metrics Explorer can produce a chart for the metric. For more information aboutcharts, seeCreate charts with Metrics Explorer.

Like all metrics in Monitoring, you can use these metrics tobuild dashboards that display multiple charts. The dashboard canrepresent metrics produced by AKS, collected by BindPlane, and stored inMonitoring. For more information about dashboards, seeView and customize Google Cloud dashboards.

vSphere on-premises cluster metrics

The last part of this example includes database metrics from vSphere. Themetrics from vSphere appear in Monitoring and can be used in thesame way as any other metric in Monitoring. TheOracle metrics from vSphere appear in the list of metrics on theMetrics Explorer page.

Like all metrics in Monitoring, metrics can be used to buildalerts. The alert can represent metrics produced by Oracle running in vSphere,collected by BindPlane, stored in Monitoring. For more informationabout alerts, seeAlerting overview.

Conclusion

Monitoring provides dashboards, alerting, and incident responsefor you to get insights into your platforms. Together, Monitoringand BindPlane provide you the ability to gain visibility into your on-premisesresources.

What's next

• Cloud Logging andCloud Monitoring
• BindPlane QuickStart Guide
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.