Un de le plus grand les coûts d’un balisage côté serveur peuvent être enregistrement. Google met en garde à ce sujet dans sa documentation officielle, et c’est certainement quelque chose à surveiller si votre point de terminaison côté serveur traite suffisamment de données par mois.
Combien doit-il traiter pour que la journalisation devienne un problème ? Cela dépend, mais vous pourriez commencer à voir un certain impact une fois que le point de terminaison traite > 1 million de requêtes entrantes par mois. La meilleure façon de savoir si la journalisation est un problème est de visiter le Facturation tableau de bord dans votre projet Google Cloud de balisage côté serveur et vérifiez quelle est la part de Volume du journal est dans vos coûts mensuels.
Dans l’image ci-dessus, le terminal traite environ 10 à 20 millions de requêtes par mois. La journalisation n’est pas un facteur de coût avant les 10 derniers jours du mois, car App Engine ne facture pas le projet le premier 50 Gio (gibioctets) de journaux. Dans ce cas particulier, l’exploitation forestière coûte environ 12 euros par mois, soit 10 % de leur coût mensuel.
Une fois que la propriété collecte plus de 100 millions de visites par mois, les journaux peuvent essentiellement dupliquer le coût mensuel, et une fois que vous collectez des quantités encore plus importantes de données, les coûts de journalisation peuvent mettre votre entreprise en faillite.
Dans cet article, je vais partager avec vous Trois conseils concernant la journalisation. Deux sur la façon de réduire les coûts et un sur la façon de trouver la sortie de journal dans un environnement de production (c’est-à-dire sans l’avantage de l’onglet Console du mode Aperçu.)
Astuce 122 : Conseils pour se connecter au balisage côté serveur
Note! Vous devriez seul filtrez les journaux de requêtes s’ils représentent un coût pour vous. Sinon, laissez-les être enregistrés – ce sont d’excellentes données pour le débogage.
Conseil n° 1 : supprimer toute journalisation des requêtes
Le moyen le plus simple de réduire les coûts consiste à empêcher App Engine de se connecter rien sur les demandes entrantes. Cela prendra essentiellement vos dépenses de journal à zéro.
L’inconvénient est que, eh bien, vous perdez le journal. Vous ne pourrez pas afficher les détails des demandes entrantes, ce qui peut être utile pour la journalisation des erreurs (voir ci-dessous).
Pour ce faire, ouvrez le Routeur de journaux pour votre projet Google Cloud (celui pour lequel votre configuration de balisage côté serveur est configurée).
Cliquez sur le menu de dépassement à la fin de la ligne du bucket nommé _Defaultet choisissez Modifier le récepteur.
Dans le Choisir les journaux à inclure dans le récepteur section, modifiez la Créer un filtre d’inclusion zone de texte et ajoutez une nouvelle ligne à la fin. Dans cette nouvelle ligne, ajoutez le texte suivant :
NOT (LOG_ID("appengine.googleapis.com/nginx.request") OR LOG_ID("requests") OR LOG_ID("appengine.googleapis.com/request_log"))
Puis clique FINI et enfin le RÉCEPTEUR DE MISE À JOUR bouton en bas de la vue.
Le filtre empêche les journaux des demandes entrantes d’être stockés dans votre stockage de journaux.
Conseil n° 2 : Supprimez la journalisation des requêtes, à l’exception des erreurs
Si vous voulez que les logs soient toujours modérément utiles tout en réduisant les coûts, vous pouvez trouver un compromis facile : supprimer tous les logs de requêtes à l’exception des erreurs. De cette façon, vous pouvez toujours utiliser les journaux pour détecter les types d’erreurs que le point de terminaison génère tout en économisant un centime ou deux en ne se connectant pas. tout.
Pour ce faire, suivez les étapes de l’astuce précédente pour ouvrir le Créer un filtre d’inclusion zone d’édition. Au lieu de l’expression de filtre détaillée dans l’astuce précédente, ajoutez ce qui suit à une nouvelle ligne :
NOT ((LOG_ID("appengine.googleapis.com/nginx.request") OR LOG_ID("requests") OR LOG_ID("appengine.googleapis.com/request_log")) AND httpRequest.status < 400)
Cliquez sur FINI et alors RÉCEPTEUR DE MISE À JOUR.
Désormais, vos requêtes ne seront pas enregistrées à moins qu’elles n’aient renvoyé un code d’état HTTP de 400 ou plus grand.
Note! Cela peut prendre un certain temps pour que le nouveau filtre commence à fonctionner, alors ne soyez pas surpris si vous continuez à voir des entrées de journal pour les demandes pendant environ une minute.
Conseil n° 3 : recherchez les journaux de la console à partir de votre trafic de production
En mode Aperçu, vous pouvez facilement trouver la sortie du journal à partir des modèles de votre conteneur en consultant le Console languette.
Mais où pouvez-vous afficher les journaux des appels qui sont ne pas disponible en mode aperçu ?
Vous devrez exécuter une requête dans le dossier de votre projet Explorateur de journaux.
Dans le Aperçu de la requête champ, ajoutez la requête suivante :
logName =~ "stdout"
Les modèles de journaux sont écrits dans un journal avec l’ID stdout (court pour sortie standard). Si vos modèles utilisent le logToConsole API, les messages enregistrés avec l’API apparaîtront avec cette requête (même ceux enregistrés en mode Aperçu).
Résumé
J’espère que ces conseils rapides ont été utiles !
Si le bricolage avec l’environnement côté serveur vous intéresse davantage, je vous recommande de vous inscrire au cours de balisage côté serveur dans Google Tag Manager sur Simmer. Les inscriptions sont ouvertes jusqu’au 14 mars 2021 (le matériel de cours sera disponible le 1er mars), et il y a un parcelle de leçons utiles en plus des conseils de journalisation dans le programme du cours !
La journalisation peut être l’un des coûts les plus importants dans un projet de balisage côté serveur, mais correctement utilisée, elle peut également vous donner beaucoup d’informations sur le fonctionnement de votre point de terminaison et sur les performances de vos balises et clients.
