La journalisation et la surveillance fonctionnent en tandem pour vous aider à comprendre et à optimiser les performances des applications, ainsi que pour diagnostiquer les erreurs les problèmes de performances. Vous devez activer les journaux récapitulatifs pour tous les appels d'API et des journaux détaillés concernant les échecs d'appels d'API, afin que vous puissiez fournir l'API ; les journaux d'appels lorsque vous avez besoin d'assistance technique.
Journalisation de la bibliothèque cliente
Les bibliothèques clientes de l'API Google Ads intègrent une fonctionnalité de journalisation. Pour les plates-formes spécifiques les détails de journalisation, consultez la documentation sur Logging dans votre bibliothèque cliente de votre choix.
Format du journal
Les bibliothèques clientes de l'API Google Ads génèrent un journal détaillé et un récapitulatif log pour chaque appel d'API. Le journal détaillé contient tous les détails de l'appel d'API, alors que le journal de résumé contient un minimum de détails sur l'appel d'API. Un exemple de chaque type de journal est affiché. Les journaux sont tronqués et mis en forme. pour plus de lisibilité.
Journal récapitulatif
GoogleAds.SummaryRequestLogs Warning: 1 : [2023-09-15 19:58:39Z] -
Request made: Host: , Method: /google.ads.googleads.v14.services.GoogleAdsService/SearchStream,
ClientCustomerID: 5951878031, RequestID: hELhBPNlEDd8mWYcZu7b8g,
IsFault: True, FaultMessage: Status(StatusCode="InvalidArgument",
Detail="Request contains an invalid argument.")
Journal détaillé
GoogleAds.DetailedRequestLogs Verbose: 1 : [2023-11-02 21:09:36Z] -
---------------BEGIN API CALL---------------
Request
-------
Method Name: /google.ads.googleads.v14.services.GoogleAdsService/SearchStream
Host:
Headers: {
"x-goog-api-client": "gl-dotnet/5.0.0 gapic/17.0.1 gax/4.2.0 grpc/2.46.3 gccl/3.0.1 pb/3.21.5",
"developer-token": "REDACTED",
"login-customer-id": "1234567890",
"x-goog-request-params": "customer_id=4567890123"
}
{ "customerId": "4567890123", "query": "SELECT ad_group_criterion.type FROM
ad_group_criterion WHERE ad_group.status IN(ENABLED, PAUSED) AND
campaign.status IN(ENABLED, PAUSED) ", "summaryRowSetting": "NO_SUMMARY_ROW" }
Response
--------
Headers: {
"date": "Thu, 02 Nov 2023 21:09:35 GMT",
"alt-svc": "h3-29=\":443\"; ma=2592000"
}
{
"results": [ {
"adGroupCriterion": {
"resourceName": "customers/4567890123/adGroupCriteria/456789456789~123456123467",
"type": "KEYWORD"
} }, {
"adGroupCriterion": {
"resourceName": "customers/4567890123/adGroupCriteria/456789456789~56789056788",
"type": "KEYWORD"
} } ],
"fieldMask": "adGroupCriterion.type", "requestId": "VsJ4F00ew6s9heHvAJ-abw"
}
----------------END API CALL----------------
Que se passe-t-il si je n'utilise pas de bibliothèque cliente ?
Si vous n'utilisez pas de bibliothèque cliente, implémentez votre propre journalisation pour capturer le
les détails des appels d'API sortants et entrants. Vous devez enregistrer au moins
de l'en-tête de réponse request-id, qui peut ensuite être partagé avec le
équipes d'assistance technique, selon les besoins.
Journalisation dans le cloud
Il existe de nombreux outils que vous pouvez utiliser pour enregistrer des journaux et des métriques de performances pour votre application. Par exemple, vous pouvez utiliser Google Cloud Logging pour consigner ces métriques de performances à votre projet Google Cloud. Ainsi, Il est possible de configurer des tableaux de bord et des alertes dans Google Cloud Monitoring. pour utiliser les métriques consignées.
Cloud Logging propose des bibliothèques clientes pour tous les clients API Google Ads compatibles. à l'exception de Perl. Dans la plupart des cas, il est donc possible Cloud Logging directement depuis l'intégration de votre bibliothèque cliente. Pour les autres langues y compris Perl, Cloud Logging propose également une API REST.
Vous disposez de plusieurs options pour vous connecter à Cloud Logging ou à un autre outil à partir d'une bibliothèque cliente de l'API Google Ads. Chaque option a ses propres compromis la mise en œuvre, la complexité et les performances. Réfléchissez bien à ces compromis avant de décider quelle solution mettre en œuvre.
Option 1: Écrire des journaux locaux dans le cloud à partir d'un processus en arrière-plan
Les journaux de la bibliothèque cliente peuvent être écrits dans un fichier local de votre ordinateur en modifiant votre configuration de journalisation. Une fois les journaux générés dans un fichier local, vous pouvez configurer un daemon pour collecter les journaux et les envoyer dans le cloud.
L'une des limites de cette approche est que certaines métriques de performances capturées par défaut. Les journaux de la bibliothèque cliente incluent les détails de la requête de réponse aux requêtes. Les métriques de latence ne seront donc pas incluses, sauf si des modifications pour les enregistrer également.
Option 2: Exécuter l'application sur Compute Engine et installer l'agent Ops
Si votre application s'exécute sur Compute Engine, vous pouvez envoyer votre les journaux à Google Cloud Logging en installant l'agent Ops. L'agent L'agent peut être configuré pour envoyer les journaux de votre application vers le cloud Logging, en plus des métriques et journaux envoyés par défaut.
Si votre application s'exécute déjà dans un environnement Google Cloud ou si vous envisagent de migrer votre application vers Google Cloud, il s'agit d'une excellente option à prendre en compte.
Option 3: Implémenter la journalisation dans le code de votre application
La journalisation directement à partir du code de l'application peut être effectuée de deux manières:
Intégrer des calculs de métriques et des instructions de journalisation dans toutes l'emplacement applicable dans votre code. Cette option est plus adaptée codebases, pour lesquels l'étendue et les coûts de maintenance d'une telle modification minimale.
Implémenter une interface de journalisation Si la logique d'application peut être abstraite afin que différents éléments de l'application héritent de la même configuration , la logique de journalisation peut être implémentée dans cette classe de base. Cette option est plutôt que d’incorporer des instructions de journalisation tout au long du code d'application, car il est plus facile à gérer et à faire évoluer. Pour les son codebase, la facilité de gestion et l'évolutivité de cette solution plus pertinents.
L'une des limites de cette approche est que les journaux de requêtes et de réponses complets sont n'est pas disponible dans le code de l'application. Les objets de requête et de réponse complets peuvent sont accessibles depuis des intercepteurs gRPC ; voici comment la bibliothèque cliente intégrée Logging obtient les journaux de requêtes et de réponses. En cas d'erreur, des informations supplémentaires des informations peuvent être disponibles dans l'objet d'exception, mais moins de détails sont disponibles pour les réponses positives dans la logique d'application. Par exemple, dans dans la plupart des cas, l'ID d'une requête réussie n'est pas accessible à partir de Objets de réponse de l'API Google Ads.
Option 4: Implémenter un intercepteur de journalisation gRPC personnalisé
gRPC est compatible avec les intercepteurs unaires et en flux continu qui peuvent accéder de requête et de réponse lors de leur transmission entre le client et le serveur. La Les bibliothèques clientes de l'API Google Ads proposent une journalisation intégrée à l'aide d'intercepteurs gRPC de l'assistance. De même, vous pouvez implémenter un intercepteur gRPC personnalisé pour accéder de requête et de réponse, extraire des informations pour la journalisation et la surveillance et écrire ces données à l'emplacement de votre choix.
Contrairement à certaines des autres solutions présentées ici, l'implémentation d'un gRPC personnalisé vous permet de capturer les objets de requête et de réponse chaque requête et implémenter une logique supplémentaire pour capturer les détails de la requête. Par exemple, vous pouvez calculer le temps écoulé d'une requête en implémentant dans l'intercepteur personnalisé lui-même, puis consignez vers Google Cloud Logging afin de la rendre disponible pour la surveillance de la latence dans Google Cloud Monitoring.
Interception Google Cloud Logging personnalisé en Python
Pour illustrer cette solution, nous avons écrit un exemple de journal personnalisé en Python. L'intercepteur personnalisé est créé et transmis au client de service. Il accède ensuite aux objets de requête et de réponse qui transmettent à chaque appel de méthode de service, traite les données de ces objets qui envoie les données à Google Cloud Logging.
Outre les données provenant des objets de requête et de réponse, implémente une logique supplémentaire pour capturer le temps écoulé la requête, et d'autres métadonnées utiles à des fins de surveillance, par exemple si la requête a abouti ou non. Pour en savoir plus sur la façon dont cela des informations peuvent être utiles, à la fois pour la surveillance et en particulier combinant Google Cloud Logging et Google Cloud Monitoring, consultez le document Monitoring guide de démarrage.
# Copyright 2022 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""A custom gRPC Interceptor that logs requests and responses to Cloud Logging.
The custom interceptor object is passed into the get_service method of the
GoogleAdsClient. It intercepts requests and responses, parses them into a
human readable structure and logs them using the logging service instantiated
within the class (in this case, a Cloud Logging client).
"""
import logging
import time
from google.cloud import logging
from grpc import UnaryUnaryClientInterceptor, UnaryStreamClientInterceptor
from google.ads.googleads.interceptors import LoggingInterceptor, mask_message
class CloudLoggingInterceptor(LoggingInterceptor):
"""An interceptor that logs rpc request and response details to Google Cloud Logging.
This class inherits logic from the LoggingInterceptor, which simplifies the
implementation here. Some logic is required here in order to make the
underlying logic work -- comments make note of this where applicable.
NOTE: Inheriting from the LoggingInterceptor class could yield unexpected side
effects. For example, if the LoggingInterceptor class is updated, this class would
inherit the updated logic, which could affect its functionality. One option to avoid
this is to inherit from the Interceptor class instead, and selectively copy whatever
logic is needed from the LoggingInterceptor class."""
def __init__(self, api_version):
"""Initializer for the CloudLoggingInterceptor.
Args:
api_version: a str of the API version of the request.
"""
super().__init__(logger=None, api_version=api_version)
# Instantiate the Cloud Logging client.
logging_client = logging.Client()
self.logger = logging_client.logger("cloud_logging")
def log_successful_request(
self,
method,
customer_id,
metadata_json,
request_id,
request,
trailing_metadata_json,
response,
):
"""Handles logging of a successful request.
Args:
method: The method of the request.
customer_id: The customer ID associated with the request.
metadata_json: A JSON str of initial_metadata.
request_id: A unique ID for the request provided in the response.
request: An instance of a request proto message.
trailing_metadata_json: A JSON str of trailing_metadata.
response: A grpc.Call/grpc.Future instance.
"""
# Retrieve and mask the RPC result from the response future.
# This method is available from the LoggingInterceptor class.
# Ensure self._cache is set in order for this to work.
# The response result could contain up to 10,000 rows of data,
# so consider truncating this value before logging it, to save
# on data storage costs and maintain readability.
result = self.retrieve_and_mask_result(response)
# elapsed_ms is the approximate elapsed time of the RPC, in milliseconds.
# There are different ways to define and measure elapsed time, so use
# whatever approach makes sense for your monitoring purposes.
# rpc_start and rpc_end are set in the intercept_unary_* methods below.
elapsed_ms = (self.rpc_end - self.rpc_start) * 1000
debug_log = {
"method": method,
"host": metadata_json,
"request_id": request_id,
"request": str(request),
"headers": trailing_metadata_json,
"response": str(result),
"is_fault": False,
"elapsed_ms": elapsed_ms,
}
self.logger.log_struct(debug_log, severity="DEBUG")
info_log = {
"customer_id": customer_id,
"method": method,
"request_id": request_id,
"is_fault": False,
# Available from the Interceptor class.
"api_version": self._api_version,
}
self.logger.log_struct(info_log, severity="INFO")
def log_failed_request(
self,
method,
customer_id,
metadata_json,
request_id,
request,
trailing_metadata_json,
response,
):
"""Handles logging of a failed request.
Args:
method: The method of the request.
customer_id: The customer ID associated with the request.
metadata_json: A JSON str of initial_metadata.
request_id: A unique ID for the request provided in the response.
request: An instance of a request proto message.
trailing_metadata_json: A JSON str of trailing_metadata.
response: A JSON str of the response message.
"""
exception = self._get_error_from_response(response)
exception_str = self._parse_exception_to_str(exception)
fault_message = self._get_fault_message(exception)
info_log = {
"method": method,
"endpoint": self.endpoint,
"host": metadata_json,
"request_id": request_id,
"request": str(request),
"headers": trailing_metadata_json,
"exception": exception_str,
"is_fault": True,
}
self.logger.log_struct(info_log, severity="INFO")
error_log = {
"method": method,
"endpoint": self.endpoint,
"request_id": request_id,
"customer_id": customer_id,
"is_fault": True,
"fault_message": fault_message,
}
self.logger.log_struct(error_log, severity="ERROR")
def intercept_unary_unary(self, continuation, client_call_details, request):
"""Intercepts and logs API interactions.
Overrides abstract method defined in grpc.UnaryUnaryClientInterceptor.
Args:
continuation: a function to continue the request process.
client_call_details: a grpc._interceptor._ClientCallDetails
instance containing request metadata.
request: a SearchGoogleAdsRequest or SearchGoogleAdsStreamRequest
message class instance.
Returns:
A grpc.Call/grpc.Future instance representing a service response.
"""
# Set the rpc_end value to current time when RPC completes.
def update_rpc_end(response_future):
self.rpc_end = time.perf_counter()
# Capture precise clock time to later calculate approximate elapsed
# time of the RPC.
self.rpc_start = time.perf_counter()
# The below call is REQUIRED.
response = continuation(client_call_details, request)
response.add_done_callback(update_rpc_end)
self.log_request(client_call_details, request, response)
# The below return is REQUIRED.
return response
def intercept_unary_stream(
self, continuation, client_call_details, request
):
"""Intercepts and logs API interactions for Unary-Stream requests.
Overrides abstract method defined in grpc.UnaryStreamClientInterceptor.
Args:
continuation: a function to continue the request process.
client_call_details: a grpc._interceptor._ClientCallDetails
instance containing request metadata.
request: a SearchGoogleAdsRequest or SearchGoogleAdsStreamRequest
message class instance.
Returns:
A grpc.Call/grpc.Future instance representing a service response.
"""
def on_rpc_complete(response_future):
self.rpc_end = time.perf_counter()
self.log_request(client_call_details, request, response_future)
# Capture precise clock time to later calculate approximate elapsed
# time of the RPC.
self.rpc_start = time.perf_counter()
# The below call is REQUIRED.
response = continuation(client_call_details, request)
# Set self._cache to the cache on the response wrapper in order to
# access the streaming logs. This is REQUIRED in order to log streaming
# requests.
self._cache = response.get_cache()
response.add_done_callback(on_rpc_complete)
# The below return is REQUIRED.
return response