Der serverside Google Tag Manager (sGTM) läuft üblicherweise über Coud Infrastruktur wie Cloud Run, oder App Engine. Die Kosten für die Nutzung setzen sich aus zwei wesentlichen Teilen zusammen:
- Cloud Run Instanzen & Anfragen: Die Konfiguration & Auslastung der Cloud Run Services
- Cloud Logging: Logs für Requests & Standardausgabe (stdout)
Da Dienste wie Cloud Run serverless sind, skalieren diese bei Bedarf auf mehrere Instanzen hoch, um alle Anfragen zu bearbeiten. Sowohl das Minimum als auch das Maximum von Instanzen kann im Tab YAML angepasst werden:
spec:
template:
metadata:
name: server-side-tagging-00001-gic
annotations:
run.googleapis.com/client-name: cloud-console
autoscaling.knative.dev/minScale: '2'
autoscaling.knative.dev/maxScale: '10'Achtung: Die Einstellung für eine mindestens Anzahl von Instanzen sorgt für dauerhafte Kosten, auch wenn keine Anfragen bearbeitet werden.
Standardmäßig werden im Docker Image vom sGTM keine Mindestanzahl von Instanzen gesetzt. Für gewöhnlich ergibt es wenig Sinn, hier einen Wert nachträglich zu setzen. Ausnahmen bestätigen die Regel.
Cloud Logging
Cloud Logging ist die Logverwaltung für die Google Cloud Platform und deckt Cloud Run und andere Services wie App Engine, oder BigQuery ab. Standardmäßig werden alle Requests und die Standardausgaben protokolliert. Bei kleineren Websites spielt das keine große Rolle, aber bei größeren Plattformen können die Logs schnell zu einer großen Kostenstelle für den Betrieb des serverseitigen Google Tag Managers werden.
Um dies zu verhindern ist es sinnvoll Logs, die nicht benötigt werden, auszuschließen. Dafür können Logs Exclusions genutzt werden. Logs, die so ausgeschlossen werden, verursachen keine Kosten, fehlen aber dann im Zweifelsfall auch zu Debugzwecken.
Logs Exclusion
Cloud Logging arbeitet mit Sinks, was im Prinzip nichts anderes ist als Auffangbehälter, in denen Logs gesammelt werden. Der Default Sink ist _Default. Hierfür können wir eine Log Exculsion anlegen, um das Aufzeichnen von Cloud Run Logs zu verhindern.
Bevor eine Filter aktiviert wird, ist sehr empfehlenswert, die Filterregeln vorher zu testen:
Der oben gezeigte Filter, welcher von Google empfohlen wird, schließt alle Requests von Cloud Run, unabhängig von der Schwere des Logs aus. Übrig bleiben würden dann in einem Inclusion Filter die stdout Logs, oder in einem Exclusion Filter das Gegenteil, alles was nicht stdout Logs sind.
Aus meiner Erfahrung ist es einfacher zu bestimmen, was man herausfiltern möchte, also eher eine Filterregel zu schreiben, die Logs bestimmt, die ausgeschlossen werden sollen. Diese lassen sich ebenfalls einfacher im Logs Explorer testen.
Ein Filterregel für den Ausschluss von allen Logs von Cloud Run, welche nicht vom Typ DEFAULT, oder Typ INFO sind könnte so aussehen.
resource.type="cloud_run_revision" AND
severity=DEFAULT OR severity=INFODieser kann dann im Logs Router bei dem _Default Sink als Logs Exclusion Filter angelegt werden.
Committed Use Discounts
Bei der GCP gibt es die Möglichkeit, Ressourcen für vordefinierte Zeiträume zu erwerben. Für App Engine gibt es diese Möglichkeit nicht, aber für fully managed Cloud Run Services kann bereits bei einer Laufzeit von einem Jahr 17 % an Kosten eingespart werden.
Dieser Rabatt war bei meinem Tests aktuell fest bei 17 % und hat sich auch nicht für niedrigere oder höhere Commitments verändert. Die Stichproben für unterschiedliche Regionen ergaben ebenfalls keinen Unterschiede im Rabatt.
Fazit
Committed Use Discounts sind neben dem Filtern von Cloud Logs ein sinnvoller Ansatz, um Kosten bei der Betreibung eines sGTM einzusparen. Ebenfalls ist mit einer Mindestlaufzeit von einem Jahr die Dauer der Verpflichtung überschaubar. Achtung: Auch wenn die reservierten Ressourcen nicht abgerufen werden, müssen diese dennoch bezahlt werden. Vor dem Erwerb eines CUD ist es also sinnvoll, die Auslastung des sGTM über einen Zeitraum zu beobachten, um dann ein passendes Kontingent an Laufzeit Stunden zu erwerben.