如需從 Python 用戶端程式庫的自訂攔截器記錄到 Google Cloud Logging 的範例，請參閱記錄指南。在 Google Cloud 中取得這些資料後，您就能根據記錄的資料建立指標，透過 Google Cloud Monitoring 掌握應用程式的狀況。請按照使用者定義記錄指標的指南操作，使用傳送至 Google Cloud Logging 的記錄建立指標。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[[["\u003cp\u003ePerformance optimization involves identifying key metrics like latency and throughput to pinpoint areas for improvement.\u003c/p\u003e\n"],["\u003cp\u003eMonitoring tools enable tracking of these metrics, setting up alerts for thresholds, and visualizing performance trends.\u003c/p\u003e\n"],["\u003cp\u003eOptimizing for latency percentiles, such as the 90th and 99th, offers a comprehensive approach to performance enhancement.\u003c/p\u003e\n"],["\u003cp\u003eServer-side and browser monitoring provide different perspectives, with server-side offering granular data and browser monitoring reflecting user experience.\u003c/p\u003e\n"],["\u003cp\u003eLeverage tools like Google Cloud Logging and Monitoring to capture, track, and analyze performance metrics, facilitating efficient optimization strategies.\u003c/p\u003e\n"]]],[],null,["# Monitoring\n\nPerformance optimization starts with identifying key metrics, usually related to\nlatency and throughput. The addition of monitoring to capture and track these\nmetrics exposes weak points in the application. With metrics, optimization can\nbe undertaken to improve performance metrics.\n\nAdditionally, many monitoring tools let you set up alerts for your metrics, so\nthat you are notified when a certain threshold is met. For example, you might\nset up an alert to notify you when the percentage of failed requests increases\nby more than *x*% of the normal levels. Monitoring tools can help you identify\nwhat normal performance looks like and identify unusual spikes in latency, error\nquantities, and other key metrics. The ability to monitor these metrics is\nespecially important during business critical timeframes, or after new code has\nbeen pushed to production.\n\nIdentify latency metrics\n------------------------\n\nEnsure that you keep your UI as responsive as you can, noting that users expect\neven higher standards from [mobile apps](/web/fundamentals/performance/why-performance-matters). Latency should also be measured\nand tracked for backend services, particularly since it can lead to throughput\nissues if left unchecked.\n\nSuggested metrics to track include the following:\n\n- Request duration\n- Request duration at subsystem granularity (such as API calls)\n- Job duration\n\nIdentify throughput metrics\n---------------------------\n\nThroughput is a measure of the total number of requests served over a given\nperiod of time. Throughput can be affected by latency of subsystems, so you\nmight need to optimize for latency to improve throughput.\n\nHere are some suggested metrics to track:\n\n- Queries per second\n- Size of data transferred per second\n- Number of I/O operations per second\n- Resource utilization, such as CPU or memory usage\n- Size of processing backlog, such as pub/sub or number of threads\n\nNot just the mean\n-----------------\n\nA common mistake in measuring performance is only looking at the mean (average)\ncase. While this is useful, it doesn't provide insight into the distribution of\nlatency. A better metric to track is the performance percentiles, for example\nthe 50th/75th/90th/99th percentile for a metric.\n\nGenerally, optimizing can be done in two steps. First, optimize for 90th\npercentile latency. Then, consider the 99th percentile---also known as tail\nlatency: the small portion of requests which take much longer to complete.\n\nServer-side monitoring for detailed results\n-------------------------------------------\n\nServer-side profiling is generally preferred for tracking metrics. The server\nside is usually much easier to instrument, allows access to more granular data,\nand is less subject to perturbation from connectivity issues.\n\nBrowser monitoring for end-to-end visibility\n--------------------------------------------\n\nBrowser profiling can provide additional insights into the end user experience.\nIt can show which pages have slow requests, which you can then correlate to\nserver-side monitoring for further analysis.\n\n[Google Analytics](/analytics) provides out-of-the-box monitoring for page load\ntimes in the [page timings report](//support.google.com/analytics/answer/1205784#PageTimings). This provides several useful views\nfor understanding the user experience on your site, in particular:\n\n- Page load times\n- Redirect load times\n- Server response times\n\nMonitoring in the cloud\n-----------------------\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThere are many tools you can use to capture and monitor performance metrics for\nyour application. For example, you can use [Google Cloud Logging](//cloud.google.com/logging) to log\nperformance metrics to your [Google Cloud Project](/google-ads/api/docs/oauth/cloud-project), then set up\ndashboards in [Google Cloud Monitoring](//cloud.google.com/monitoring) to monitor and segment the logged\nmetrics.\n\nCheck out the [Logging guide](/google-ads/api/docs/productionize/logging) for an [example](/google-ads/api/docs/productionize/logging#option_4_implement_a_custom_grpc_logging_interceptor) of logging to\nGoogle Cloud Logging from a custom interceptor in the Python client library.\nWith that data available in Google Cloud, you can build metrics on top of the\nlogged data to gain visibility into your application through Google Cloud\nMonitoring. Follow the [guide](//cloud.google.com/logging/docs/logs-based-metrics#user-defined_metrics) for user-defined log-based metrics to\nbuild metrics using the logs sent to Google Cloud Logging.\n\nAlternatively, you could use the Monitoring client [libraries](//cloud.google.com/monitoring/docs/reference/libraries) to define\nmetrics in your code and send them directly to Monitoring, separate from the\nlogs.\n\n### Log-based metrics example\n\nSuppose you want to monitor the `is_fault` value to better understand error\nrates in your application. You can extract the `is_fault` value from the logs\ninto a new [counter metric](//cloud.google.com/logging/docs/logs-based-metrics/counter-metrics), `ErrorCount`.\n\nIn Cloud Logging, [labels](//cloud.google.com/logging/docs/logs-based-metrics/labels) let you group your metrics into categories\nbased on other data in the logs. You can configure a label for the [`method`\nfield sent to Cloud Logging](/google-ads/api/docs/productionize/logging#option_4_implement_a_custom_grpc_logging_interceptor) in order to look at how the error count is\nbroken down by the Google Ads API method.\n\nWith the `ErrorCount` metric and the `Method` label configured, you can [create\na new\nchart](//cloud.google.com/logging/docs/logs-based-metrics/charts-and-alerts) in\na Monitoring dashboard to monitor `ErrorCount`, grouped by `Method`.\n\n### Alerts\n\nIt's possible in Cloud Monitoring and in other tools to configure alert policies\nthat specify when and how alerts should be triggered by your metrics. For\ninstructions on setting up Cloud Monitoring alerts, follow the\n[alerts guide](//cloud.google.com/logging/docs/logs-based-metrics/charts-and-alerts#alert-on-lbm)."]]
