作为示例,ExampleOrganization 将资源部署到 Google Cloud和 Microsoft Azure,并使用 vSphere 部署本地资源。Google Cloud中部署了一个 GKE 集群和一个演示版应用,用于运行公司的网站。在 Microsoft Azure 环境中,Azure Kubernetes Service (AKS) 运行着一组微服务,为外部开发者提供 REST API 端点。在 vSphere 环境中,MySQL、Oracle 和 Microsoft SQL Server 支持多个企业应用。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2024-08-02。"],[[["\u003cp\u003eThis document focuses on using BindPlane to extend Cloud Monitoring to on-premises resources, as part of a series that also covers extending Cloud Logging.\u003c/p\u003e\n"],["\u003cp\u003eBindPlane offers a configuration-based approach to ingest metrics into Cloud Monitoring from on-premises or other cloud sources, presenting an alternative to directly using the Cloud Monitoring API.\u003c/p\u003e\n"],["\u003cp\u003eBindPlane supports various sources, agents, destinations, and processors, making it adaptable for environments like Google Cloud, Azure, and vSphere.\u003c/p\u003e\n"],["\u003cp\u003eOnce metrics are sent from BindPlane to Cloud Monitoring, they can be viewed, configured, and used for alerting and dashboards within the Monitoring Workspace.\u003c/p\u003e\n"],["\u003cp\u003eUsing BindPlane to ingest metrics into Monitoring is the recommended method because it prioritizes configuration over app instrumentation, reducing implementation time and effort.\u003c/p\u003e\n"]]],[],null,["# Monitor on-premises resources with BindPlane\n\nThis document is one part of a two-part series on extending Cloud Logging\nand Cloud Monitoring to include on-premises infrastructure and apps.\n\n- [Log on-premises resources with BindPlane](/architecture/logging-on-premises-resources-with-bindplane): Read about how Cloud Logging supports logging from on-premises resources.\n- Monitor on-premises resources with BindPlane (this document): Read about how Cloud Monitoring supports monitoring of on-premises resources.\n\nYou might consider using Logging and Monitoring\nfor logging and monitoring of your on-premises resources for the following\nreasons:\n\n- You need a temporary solution as you move infrastructure to Google Cloud and you want to monitor your on-premises resources until they're decommissioned.\n- You might have a diverse computing environment with multiple clouds and on-premises resources.\n\nIn either case, with the Logging and Monitoring\nAPIs and\n[BindPlane](https://observiq.com/solutions),\nyou can gain visibility into your on-premises resources. This document is\nintended for DevOps practitioners, managers, and executives who are interested\nin a monitoring strategy for resources in Google Cloud and their remaining\non-premises infrastructure and apps.\n\nIngesting metrics with Monitoring\n---------------------------------\n\nYou can get metrics into Monitoring in the following two ways:\n\n- Use BindPlane from observIQ to ingest metrics from your on-premises or other cloud sources.\n- Use OpenCensus to write to the Cloud Monitoring API.\n\n### Using BindPlane to ingest metrics\n\nThe following diagram shows the architecture of how BindPlane collects metrics\nand then how these metrics are ingested into Monitoring.\n\nobservIQ offers several versions of BindPlane: BindPlane for Google, self-hosted,\nSaaS, and Enterprise. For more information about these versions, see the [BindPlane\nsolutions page](https://observiq.com/solutions).\n\nAdvantages:\n\n- Requires configuration, not instrumentation of your apps, which reduces time to implement.\n- Included in the cost of using [Monitoring](/stackdriver/pricing).\n- Supported configuration by Monitoring product and support.\n- Can extend to metrics not provided by the default configuration.\n\nDisadvantages:\n\n- Requires the use of the observIQ BindPlane agent to relay metrics to Monitoring, which can add complexity to the overall system.\n\nThis option is the recommended method because it requires the lowest amount of\neffort. This solution requires configuration rather than development.\n\n### Using OpenCensus to write to the Monitoring API\n\nThe following diagram shows the architecture of how OpenCensus collects metrics\nand how these metrics are ingested into Monitoring.\n\nUsing the Monitoring API directly means that you need to add\ninstrumentation code to your apps to send metrics directly to the API. You can\ndo this directly by\n[using the Monitoring API to write metrics](/monitoring/custom-metrics/creating-metrics#writing-ts)\nor by instrumenting your app with the\n[Monitoring exporter for OpenCensus](https://opencensus.io/exporters/supported-exporters/python/stackdriver/).\nOpenCensus is an open source project that defines a standard data structure for\ntraces and metrics. Using OpenCensus has the advantage of supporting multiple\nbackends, including Monitoring. Using OpenCensus also implements\nall the low-level technical details of using the Monitoring API.\n\nAdvantages:\n\n- Provides flexibility because the instrumentation required is easily implemented with the use of the OpenCensus Exporter\n\nDisadvantages:\n\n- Requires a separate solution for infrastructure metrics by writing a custom agent.\n- Requires app instrumentation, which might mean higher cost to implement.\n- Requires open source libraries.\n\nThis option isn't the recommended method because it requires the highest amount\nof effort and doesn't cover infrastructure metrics.\n\nUsing BindPlane\n---------------\n\nThis document covers using BindPlane from observIQ to ingest metrics\ninto Monitoring. The BindPlane service works by defining a series\nof sources, ingesting those metrics, and then sending the metrics to\nMonitoring as the destination. BindPlane supports\nagents that run on [select versions](https://observiq.com/docs/advanced-setup/installation/install-agent) of Windows, Linux, and Kubernetes.\n\n### Sources, agents, destinations, and processors\n\nBindPlane has the following features:\n\n- **[Sources](https://observiq.com/docs/resources/sources)**: Items that generate metrics such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes (Amazon EKS), or Microsoft Azure Container Service.\n- **[Agents](https://observiq.com/docs/going-to-production/bindplane-agent)**: Lightweight processes that remotely monitor your environment and forward metric data to BindPlane.\n- **[Destinations](https://observiq.com/docs/resources/destinations)**: Services that BindPlane forwards the metrics. In this case, the destination is the process on BindPlane that uses the Monitoring API to write metrics to Monitoring.\n- **[Processors](https://observiq.com/docs/resources/processors)**: Configurations that can transform your data before it arrives at your destination. This includes adding attributes, filtering, and converting logs to metrics.\n\nFor more detailed information about sources, agents, destinations, and processors,\nsee the [BindPlane QuickStart Guide](https://observiq.com/docs/getting-started/quickstart-guide).\n\n### Example use case\n\nAs an example, ExampleOrganization has resources deployed to Google Cloud,\nMicrosoft Azure, and on-premises resources deployed by using vSphere. In\nGoogle Cloud, there is a GKE cluster and a demo app\ndeployed, which runs the company's website. In the Microsoft Azure environment,\nAzure Kubernetes Service (AKS) is running a set of microservices, providing a\nREST API endpoint to external developers. In the vSphere environment,\nMySQL, Oracle, and Microsoft SQL Server support several corporate apps.\n\nWith resources in each environment, ExampleOrganization wants to monitor each\ncomponent regardless of where the component is deployed. Sending the metrics\nfrom each environment to Logging and Monitoring by\nusing BindPlane brings all the metrics into a single location for monitoring and\nalerting purposes.\n\n### Send metrics from BindPlane to Monitoring\n\nAfter BindPlane is set up and begins sending metrics, those metrics are sent to\nyour Monitoring Workspace. You can then use\nMonitoring to view, configure, alert, and build dashboards from\nthe time series like you can for any metrics or time series in Monitoring. For\nmore information, see\n[Metrics, time series, and resources](/monitoring/api/v3/metrics).\n\n### Use metrics in Monitoring\n\nIn the previous example, BindPlane was configured to send metrics from\nGoogle Cloud, Microsoft Azure, and on-premises sources. The following three\nmetrics appear in Monitoring:\n\n- GKE cluster metrics\n- AKS cluster metrics\n- vSphere on-premises database metrics\n\n#### GKE cluster metrics\n\nIf you have GKE clusters set up, the GKE cluster metrics\nappear in the [Kubernetes Clusters page](https://console.cloud.google.com/kubernetes/list/overview)\nor [Kubernetes Workloads page](https://console.cloud.google.com/kubernetes/workload/overview).\nYou can see multiple views of the Kubernetes components\nrunning in Monitoring. The metrics, logs, and configuration are\navailable for each pod.\n\nFor details, see [View observability metrics](/kubernetes-engine/docs/how-to/view-observability-metrics).\n\n#### AKS cluster metrics\n\nIn the same\n[Monitoring](https://console.cloud.google.com/monitoring)\nenvironment, metrics for AKS are collected. The metrics appear in\nMonitoring and can be used for any purposes in\nMonitoring including dashboards, alerting, and the Metrics\nExplorer.\n\nThe [Metrics Explorer page](https://console.cloud.google.com/monitoring/metrics-explorer) provides a way to find, filter,\nand build charts from metrics. Note that the metrics sent in by BindPlane have\nthe `workload.googleapis.com/`\u003cvar translate=\"no\"\u003eTHIRD_PARTY_APP_NAME\u003c/var\u003e\nprefix for the metric name.\n\nThe Metrics Explorer can produce a chart for the metric. For more information about\ncharts, see [Create charts with Metrics Explorer](/monitoring/charts/metrics-explorer).\n\nLike all metrics in Monitoring, you can use these metrics to\nbuild dashboards that display multiple charts. The dashboard can\nrepresent metrics produced by AKS, collected by BindPlane, and stored in\nMonitoring. For more information about dashboards, see [View and customize Google Cloud dashboards](/monitoring/charts/predefined-dashboards).\n\n#### vSphere on-premises cluster metrics\n\nThe last part of this example includes database metrics from vSphere. The\nmetrics from vSphere appear in Monitoring and can be used in the\nsame way as any other metric in Monitoring. The\nOracle metrics from vSphere appear in the list of metrics on the [Metrics Explorer page](https://console.cloud.google.com/monitoring/metrics-explorer).\n\nLike all metrics in Monitoring, metrics can be used to build\nalerts. The alert can represent metrics produced by Oracle running in vSphere,\ncollected by BindPlane, stored in Monitoring. For more information\nabout alerts, see [Alerting overview](/monitoring/alerts).\n\nConclusion\n----------\n\nMonitoring provides dashboards, alerting, and incident response\nfor you to get insights into your platforms. Together, Monitoring\nand BindPlane provide you the ability to gain visibility into your on-premises\nresources.\n\nWhat's next\n-----------\n\n- [Cloud Logging](/logging) and [Cloud Monitoring](/monitoring)\n- [BindPlane QuickStart Guide](https://observiq.com/docs/getting-started/quickstart-guide)\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]