Kostenoptimierung für Google Cloud Observability

Google Cloud Observability besteht aus einer Sammlung von cloudbasierten verwalteten Diensten, die eine hohe Beobachtbarkeit für Anwendungs- und Infrastrukturdienste ermöglichen. Einer der Vorteile von verwalteten Diensten in Google Cloud ist, dass die Dienste nutzungsbasiert sind, d. h. Sie zahlen nur für die tatsächliche Nutzung. Im Vergleich zur Standardsoftwarelizenz bietet dieses Preismodell einen Kostenvorteil, mitunter kann es jedoch schwierig sein, eine Kostenprognose zu erstellen. In dieser Lösung wird beschrieben, wie Sie Ihre Nutzung dieser Dienste prüfen und die Kosten optimieren können.

Preise

Da die Google Cloud Observability-Dienste verwaltete Dienste sind, können Sie sich auf die damit gewonnenen Informationen anstatt auf die für die Nutzung dieser Dienste nötige Infrastruktur konzentrieren. Wenn Sie diese Dienste nutzen, müssen Sie nicht für jeden Dienst separat für virtuelle Maschinen, Softwarelizenzen, Sicherheitsscans, Hardwarewartung oder Speicherplatz in einem Rechenzentrum zahlen. Die Abrechnung erfolgt einfach auf Nutzungsbasis.

Die Kosten beinhalten die Kosten für Cloud Logging, Cloud Monitoring und Cloud Trace. Das Logging-Produkt von Error Reporting verursacht während der Betaphase keine separaten Kosten. Sie können Cloud Profiler kostenlos nutzen. Für Error Reporting können geringe Kosten anfallen, wenn die Fehler von Logging aufgenommen werden.

Sie können auch eine Zusammenfassung aller Preisinformationen lesen.

Kosten für Logging und Fehlerberichte

Die Logging-Preise richten sich nach dem Volumen der aufgenommenen kostenpflichtigen Logs. Das Preismodell ermöglicht die einfache Abrechnung pro GiB. Pro Monat gibt es eine kostenlose Zuteilung. Bestimmte Logs, beispielsweise Logs von Cloud-Audit-Logging, sind nicht kostenpflichtig.

Kosten ergeben sich durch zusätzliches Logvolumen, das z. B. durch die Nutzung der folgenden Tools entsteht:

  • Cloud Load Balancing
  • Logging-Agent auf Compute Engine
  • Logging-Agent für Amazon Web Services (AWS)
  • Der Schreibvorgang in der Cloud Logging API

Kosten für Monitoring

Die Monitoring-Preise richten sich nach der Menge der aufgenommenen kostenpflichtigen Messwerte und der Anzahl der kostenpflichtigen API-Aufrufe. Kostenpflichtig sind zum Beispiel Messwerte, die nicht von Google Cloud stammen, etwa Agent- und AWS-Messwerte sowie benutzerdefinierte und externe Messwerte. Für die Methode projects.timeSeries.list in der Cloud Monitoring API wird jeder API-Aufruf abgerechnet, während die restliche API-Nutzung kostenlos ist. Es gibt ein kostenloses Kontingent an Messwertvolumen pro Monat. Viele Messwerte, z. B. alle Google Cloud-Messwerte, sind nicht kostenpflichtig. Weitere Informationen dazu, welche Messwerte kostenpflichtig sind, finden Sie unter Monitoring-Preise.

Kosten ergeben sich beispielsweise durch Messwertvolumen und API-Aufrufe bei Nutzung der folgenden Tools:

  • Benutzerdefinierte Messwerte in Monitoring
  • Monitoring-Agent in Compute Engine
  • Monitoring-Agent in AWS
  • Lesevorgang in der Monitoring API

Kosten für Trace

Die Trace-Preise richten sich nach der Anzahl der aufgenommenen und früher oder später gescannten Spans. Einige Google Cloud-Dienste, z. B. die App Engine-Standardumgebung, erzeugen automatisch kostenlose Spans. Für Trace gibt es eine kostenlose Zuteilung pro Monat.

Kosten für die Aufnahme von Spans ergeben sich beispielsweise durch das Hinzufügen von Instrumentierung für die folgenden Komponenten:

  • Spans für App Engine-Anwendungen außerhalb der Standard-Spans
  • Cloud Load Balancing
  • Benutzerdefinierte Anwendungen

Nutzung

Verschaffen Sie sich einen detaillierten Überblick über Ihre Nutzung und ermitteln Sie die Komponenten, die Kosten generieren. So haben Sie die Möglichkeit, die Bereiche zu ermitteln, die sich optimieren lassen.

Analyse der Google Cloud-Abrechnungen

Der erste Schritt für einen Überblick über Ihre Nutzung besteht darin, Ihre Google Cloud-Abrechnung zu prüfen. Darin sind alle Kosten erfasst. Sie können z. B. die in der Google Cloud Console verfügbaren Rechnungsberichte aufrufen.

Auf der Seite "Berichte" gibt es eine Reihe nützlicher Filter, mit denen Sie die Ergebnisse nach Zeit, Projekt, Produkten, Artikelnummern und Labeln eingrenzen können. Mit dem Produktfilter können Sie die Abrechnungsdaten auf Monitoring- und Logging-Kosten eingrenzen.

Logging

In Logging sind alle Logs, aktuelle Logvolumen sowie die für jedes Projekt vorausberechneten monatlichen Volumen detailliert aufgeführt. Wenn Sie die Logging-Gebühren auf Ihrer Google Cloud-Rechnung prüfen, können Sie auch diese Details für jedes Projekt einzeln prüfen. So können Sie schnell und mühelos die Logs mit den höchsten Volumen und damit dem höchsten Kostenanteil ermitteln.

Im Log-Speicher finden Sie das Logvolumen, das in Ihr Projekt aufgenommen wurde. Auf der Seite Logspeicher finden Sie eine Liste der Logs und ihrer Volumen für den vorherigen Monat und den aktuellen Monat sowie die prognostizierten Volumen für das Monatsende.

Diese Analysen ermöglichen einen detaillierten Überblick über die Lognutzung in bestimmten Projekten und die Volumenentwicklung im Zeitverlauf. Auf der Grundlage der Daten ist es dann problemlos möglich, die Logs mit Optimierungspotenzial zu ermitteln.

Monitoring

Das in Messwertbereichen gegliederte Monitoring bietet eine detaillierte Auflistung der Projekte mit Angabe des Messwertdatenvolumens im Vormonat und aktuellen Monat sowie einer Prognose des Volumens bis Ende des Monats. Da ein Messwertbereich mehrere Projekte enthalten kann, werden die Volumen für jedes Projekt separat aufgeführt, wie in der folgenden Abbildung dargestellt.

Arbeitsbereich mit mehreren Projekten

Informationen zur Monitoring-Nutzungsdetails.

Im Messwert-Explorer von Monitoring werden die aufgenommenen Messwertdatenvolumen aufgeschlüsselt nach Projekt in einer detaillierten Grafik angezeigt. So erhalten Sie einen Überblick über das Messwertvolumen im Zeitverlauf.

In dieser Analyse werden die Messwertvolumen der Projekte angezeigt, die Sie bei Prüfung der Monitoring-Gebühren auf der Google Cloud-Abrechnung identifiziert haben. Sie können die jeweiligen Messwertvolumen prüfen und herausfinden, welche Komponenten den größten Anteil am Volumen und an den Kosten haben.

Trace

In Trace erhalten Sie eine detaillierte Ansicht der im aktuellen und im Vormonat aufgenommenen Spans. Sie können diese Details in der Google Cloud Console für alle Projekte einsehen, die Sie bei der Prüfung Ihrer Trace-Gebühren auf der Google Cloud-Abrechnung identifiziert haben.

In dieser Analyse sehen Sie die Anzahl der Spans, die für die einzelnen Projekte in einen Arbeitsbereich aufgenommen wurden, den Sie bei Prüfung der Trace-Gebühren auf der Google Cloud-Abrechnung identifiziert haben. Sie können sich dann die jeweilige Anzahl der aufgenommenen Spans ansehen und herausfinden, welche Projekte und Dienste den größten Span- und Kostenanteil ausmachen.

Logging-Export

In Logging gibt es eine Senke, mit der Sie Logs in Cloud Storage, BigQuery und Cloud Pub/Sub exportieren können.

Beispiel: Sie exportieren alle Logging-Logs zum Zweck der langfristigen Speicherung und Analyse in BigQuery. In diesem Fall umfassen die Ihnen für BigQuery berechneten Kosten auch die Speicherkosten pro GiB, die Kosten für Streaming-Insert-Anweisungen und eventuelle Kosten für Abfragen.

Mit den folgenden Schritten können Sie sich einen Überblick über die Kosten verschaffen, die durch Exporte generiert werden:

  1. Logging-Senken finden. Sie können herausfinden, welche Logging-Senken Sie gegebenenfalls aktiviert haben. Ihr Projekt kann bereits mehrere Logging-Senken haben, die für verschiedene Zwecke erstellt wurden, z. B. für Sicherheitsvorgänge oder zur Einhaltung regulatorischer Anforderungen.
  2. Nutzungsdetails prüfen. Sie können die Nutzung am Ziel der Exporte überprüfen, also beispielsweise die Tabellengrößen bei BigQuery-Exporten oder die Bucket-Größen bei Cloud Storage-Exporten.

Logging-Senken finden

Die Logging-Senken können sich auf Projektebene (eine oder mehrere Senken pro Projekt) oder auf Ebene der Google Cloud-Organisation (aggregierte Exporte) befinden. Sie können die Logs vieler Projekte in derselben Google Cloud-Organisation enthalten.

Die Logging-Senken werden angezeigt, wenn Sie sich bestimmte Projekte ansehen. Die Google Cloud Console stellt eine Liste der Senken und des Ziels bereit. Sie können die aggregierten Exporte für Ihre Organisation mit der gcloud logging sinks list --organization ORGANIZATION_ID-Befehlszeile aufrufen.

Nutzungsdetails überprüfen

Monitoring bietet eine Vielzahl von Messwerten, nicht nur für Anwendungen, sondern auch für die Nutzung von Google Cloud-Produkten. Im Metrics Explorer haben Sie auch Zugriff auf detaillierte Nutzungsmesswerte für Cloud Storage, BigQuery und Cloud Pub/Sub.

Cloud Storage

Im Messwert-Explorer in Monitoring wird die Speichergröße für Ihre Cloud Storage-Buckets angezeigt. Im Messwert-Explorer geben Sie die folgenden Werte ein, um die Speichergröße Ihrer für die Logging-Senken verwendeten Cloud Storage-Buckets zu ermitteln.

So rufen Sie mit dem Metrics Explorer die Messwerte für eine überwachte Ressource auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics Explorer

  2. Maximieren Sie im Element Messwert das Menü Messwert auswählen, geben Sie Total bytes in die Filterleiste ein und wählen Sie dann über die Untermenüs einen bestimmten Ressourcentyp und Messwert aus:
    1. Wählen Sie im Menü Aktive Ressourcen die Option GCS-Bucket aus.
    2. Wählen Sie im Menü Aktive Messwertkategorien die Option Speicher aus.
    3. Wählen Sie im Menü Aktive Messwerte die Option Bytes insgesamt aus.
    4. Klicken Sie auf Anwenden.
    Der voll qualifizierte Name für diesen Messwert ist storage.googleapis.com/storage/total_bytes.
  3. Konfigurieren Sie, wie die Daten angezeigt werden.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie dann project_id aus. Wählen Sie als Wert Ihre Google Cloud-Projekt-ID aus.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie bucket_name aus. Wählen Sie als Wert den Namen des Cloud Storage-Export-Buckets aus.
    • Legen Sie im Eintrag Aggregation das erste Menü auf Nicht aggregiert fest.

    Weitere Informationen zum Konfigurieren eines Diagramms finden Sie unter Messwerte bei Verwendung von Metrics Explorer auswählen.

Speichergröße von Cloud Storage-Buckets

Das Diagramm oben zeigt die Größe (in TB) der exportierten Daten im Zeitverlauf an. So erhalten Sie einen Überblick über die Nutzung des Logging-Exports in Cloud Storage.

BigQuery

Im Messwert-Explorer in Monitoring können Sie die Speichergröße für BigQuery-Datasets anzeigen. Geben Sie dazu im Messwert-Explorer die folgenden Werte ein, um die Speichergröße Ihres für die Logging-Senken verwendeten BigQuery-Datasets zu ermitteln.

So rufen Sie mit dem Metrics Explorer die Messwerte für eine überwachte Ressource auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics Explorer

  2. Maximieren Sie im Element Messwert das Menü Messwert auswählen, geben Sie Stored bytes in die Filterleiste ein und wählen Sie dann über die Untermenüs einen bestimmten Ressourcentyp und Messwert aus:
    1. Wählen Sie im Menü Aktive Ressourcen die Option BigQuery-Dataset aus.
    2. Wählen Sie im Menü Aktive Messwertkategorien die Option Speicher aus.
    3. Wählen Sie im Menü Aktive Messwerte die Option Gespeicherte Bytes aus.
    4. Klicken Sie auf Anwenden.
    Der voll qualifizierte Name für diesen Messwert ist bigquery.googleapis.com/storage/stored_bytes.
  3. Konfigurieren Sie, wie die Daten angezeigt werden.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie dann project_id aus. Wählen Sie als Wert Ihre Google Cloud-Projekt-ID aus.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie dann dataset_id aus. Wählen Sie für den Wert den Namen des BigQuery-Export-Datasets aus.
    • Legen Sie im Eintrag Aggregation das erste Menü auf Mittelwert und das zweite Menü auf dataset_id fest.
    • Legen Sie im Bereich Anzeige den Widgettyp auf Gestapeltes Balkendiagramm fest.
    • Legen Sie als Zeitfenster mindestens einen Tag fest.

    Weitere Informationen zum Konfigurieren eines Diagramms finden Sie unter Messwerte bei Verwendung von Metrics Explorer auswählen.

Screenshot: Speichergröße des BigQuery-Datasets

Das Diagramm oben zeigt die Größe (in TB) des Export-Datasets im Zeitverlauf. Es bietet einen guten Überblick über die Nutzung des Logging-Exports in BigQuery.

Pub/Sub

Im Metrics Explorer in Monitoring werden Anzahl und Größe der in Cloud Pub/Sub exportierten Nachrichten angezeigt. Geben Sie im Metrics Explorer die folgenden Werte ein, um die Speichergröße Ihrer für die Logging-Senken verwendeten Cloud Pub/Sub-Themen anzusehen.

So rufen Sie mit dem Metrics Explorer die Messwerte für eine überwachte Ressource auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics Explorer

  2. Maximieren Sie im Element Messwert das Menü Messwert auswählen, geben Sie Byte cost in die Filterleiste ein und wählen Sie dann über die Untermenüs einen bestimmten Ressourcentyp und Messwert aus:
    1. Wählen Sie im Menü Aktive Ressourcen Cloud Pub/Sub-Thema aus.
    2. Wählen Sie im Menü Aktive Messwertkategorien Thema aus.
    3. Wählen Sie im Menü Aktive Messwerte Themen-Byte-Kosten aus.
    4. Klicken Sie auf Anwenden.
    Der voll qualifizierte Name für diesen Messwert ist pubsub.googleapis.com/topic/byte_cost.
  3. Konfigurieren Sie, wie die Daten angezeigt werden.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie dann project_id aus. Wählen Sie als Wert Ihre Google Cloud-Projekt-ID aus.
    • Klicken Sie im Element Filter auf Filter hinzufügen und wählen Sie dann topic_id aus. Wählen Sie als Wert den Namen des Pub/Sub-Exportthemas aus.
    • Legen Sie im Eintrag Aggregation das erste Menü auf Nicht aggregiert fest.

    Weitere Informationen zum Konfigurieren eines Diagramms finden Sie unter Messwerte bei Verwendung von Metrics Explorer auswählen.

Screenshot: Speichergröße des Pub/Sub-Themas Das vorherige Diagramm zeigt die Größe (in KB) der exportierten Daten im Zeitverlauf an. So erhalten Sie einen Überblick über die Nutzung des Logging-Exports in Pub/Sub.

Kostenkontrolle implementieren

Es gibt mehrere Möglichkeiten, wie Sie Ihre Kosten reduzieren können. Jede der Möglichkeiten bedeutet aber gleichzeitig eine Einschränkung des umfassenden Überblicks über Ihre Anwendungen und Infrastruktur. Wählen Sie die Möglichkeit, die für Sie den besten Kompromiss zwischen Beobachtbarkeit und Kostenreduzierung bietet.

Kostenkontrollen für Logging

Zur Optimierung der Logging-Nutzung können Sie die Anzahl der Logs reduzieren, die in Logging aufgenommen werden. Es gibt verschiedene Strategien, mit denen Sie das Logvolumen reduzieren, jedoch gleichzeitig die Logs erhalten können, die von den Entwicklern und Betreibern benötigt werden.

Logs ausschließen

Die meisten Logs, die von Ihren Entwickler- und Betriebsteams nicht benötigt werden, können von Logging oder Error Reporting ausgeschlossen werden.

Das Ausschließen von Logs bedeutet, dass sie nicht in der Logging- oder Error Reporting-Benutzeroberfläche angezeigt werden. Sie können mit Logging-Filtern bestimmte Logeinträge oder ganze Logs auswählen, die ausgeschlossen werden sollen. Mithilfe von Ausschlussregeln der Datenerfassung können Sie auch einen prozentualen Anteil von Logging-Einträgen ausschließen. Kriterien für den Ausschluss von Logs sind zum Beispiel hohes Volumen oder fehlender praktischer Wert.

Hier einige gängige Beispiele für Ausschlüsse:

  • Logs von Cloud Load Balancing ausschließen. Load-Balancer generieren für Anwendungen mit hohem Traffic häufig ein großes Logvolumen. Mithilfe eines Filters könnten Sie z. B. 90 % der Nachrichten von Cloud Load Balancing ausschließen.
  • Flusslogs für Virtual Private Cloud (VPC Service Controls) ausschließen. Flusslogs enthalten Logs zu jeder Kommunikation zwischen virtuellen Maschinen in einem VPC Service Controls-Netzwerk und können daher ein großes Logvolumen verursachen. Es gibt zwei Ansätze zur Reduzierung des Logvolumens, die zusammen oder getrennt angewendet werden können.

    • Nach Inhalt des Logeintrags ausschließen. Mit diesem Ansatz werden die meisten VPC-Flusslogs ausgeschlossen. Es bleiben nur spezifische Lognachrichten erhalten, die eventuell nützlich sein könnten. Beispiel: Wenn Ihre privaten VPCs keinen eingehenden Datenverkehr von externen Quellen erhalten sollen, bietet es sich an, nur Flusslogs mit Quellfeldern von externen IP-Adressen zu behalten.
    • Nach Prozentsatz ausschließen. Mit diesem Ansatz wird nur ein prozentualer Anteil der vom Filter erkannten Logs erfasst. Beispiel: Sie möchten 95 % der Flusslogs ausschließen und nur 5 % behalten.
  • HTTP-Antworten 200 OK aus Anfragelogs ausschließen Für Anwendungen sind HTTP-200 OK-Nachrichten von geringer Aussagekraft. Bei Anwendungen mit hohem Traffic können sie jedoch ein großes Logvolumen generieren.

Informationen zur Implementierung von Logausschlüssen finden Sie unter Logausschlüsse.

Logs exportieren

Sie können Logs exportieren und gleichzeitig von der Aufnahme in Logging ausschließen. Die exportierten Logs werden in Cloud Storage und BigQuery aufbewahrt oder mit Cloud Pub/Sub verarbeitet, sind aber von Logging ausgeschlossen. Auch mit diesem Ansatz können Sie Kosten sparen. Ihre Logs werden in Logging nicht angezeigt, werden aber dennoch exportiert.

Dieser Ansatz ist geeignet, um Logs für längerfristige Analysen aufzubewahren, ohne dass Kosten für die Aufnahme in Logging anfallen. Für ein besseres Verständnis des Zusammenwirkens von Ausschlüssen und Exporten sollten Sie sich das Diagramm "Life of a log" ansehen. Es veranschaulicht die Behandlung exportierter Logeinträge in Logging.

Nutzung von Logging-Agent reduzieren

Eine weitere Möglichkeit, Logvolumen zu reduzieren, besteht darin, die vom Logging-Agent generierten zusätzlichen Logs nicht an Logging zu senden. Der Logging-Agent streamt Logs von gängigen Drittanbieteranwendungen wie Apache, MongoDB und MySQL.

Sie können beispielsweise festlegen, dass der Logging-Agent keinen virtuellen Maschinen in Ihrer Entwicklungsumgebung oder anderen für Logging unwichtigen Umgebungen hinzugefügt wird. Die virtuellen Maschinen melden die Standardlogs weiterhin, melden aber keine Logs von Drittanbieteranwendungen oder dem Syslog an Logging.

Kostenkontrollen für Monitoring

Zur Optimierung Ihrer Monitoring-Nutzung können Sie das Volumen der in Monitoring aufgenommenen kostenpflichtigen Messwerte und die Anzahl der Leseaufrufe der Monitoring API reduzieren. Es gibt verschiedene Strategien, mit denen Sie das Messwertvolumen reduzieren und gleichzeitig die von Ihren Entwicklern und Betreibern benötigten Messwerte behalten können.

Messwert- und Labelverwendung optimieren

Die Menge der generierten Zeitachsen kann sich auf die Art und Weise auswirken, wie Sie Labels für benutzerdefinierte Monitoring-Messwerte verwenden.

Wenn Sie einen benutzerdefinierten Messwert mit zwei Labels haben, z. B. cost_center- und env-Werte, können Sie die maximale Anzahl von Zeitachsen berechnen, wenn Sie die Kardinalität der beiden Labels multiplizieren.

total_num_time_series = cost_center_cardinality * env_cardinality

Bei 11 cost_center-Werten und 5 env-Werten können bis zu 55 Zeitachsen generiert werden. Aus diesem Grund kann das Hinzufügen zusätzlicher Messwertlabels zu einem erheblichen Messwertvolumen führen und damit die Kosten erhöhen. Eine ausführliche Beschreibung der Kardinalität von Messwerten finden Sie im Blogpost Stackdriver tips and tricks: Understanding metrics and building charts.

Wir empfehlen das folgende Vorgehen, um die Anzahl der Zeitachsen zu minimieren:

  • Nach Möglichkeit sollten Sie die Anzahl der benutzerdefinierten Messwertlabels begrenzen.
  • Sie müssen die Labels sorgfältig auswählen, um Labelwerte mit hoher Kardinalität zu vermeiden. Beispiel: Wenn Sie user_id als Label verwenden, führt dies zu mindestens einer Zeitreihe für jeden Nutzer, was bei sehr vielen Zugriffen eine sehr große Anzahl sein kann.

Nutzung von Monitoring-Agents reduzieren

Vom Monitoring-Agent gesendete Messwerte sind kostenpflichtig. Der Monitoring-Agent streamt Anwendungs- und Systemmesswerte von gängigen Drittanbieteranwendungen wie Apache, MySQL und Nginx sowie zusätzliche Messwerte auf Google Cloud VM-Ebene. Werden für bestimmte VMs keine detaillierten Systemmesswerte oder Messwerte von Drittanbieteranwendungen benötigt, können Sie das Volumen reduzieren, wenn Sie diese Messwerte nicht senden. Das Messwertvolumen kann auch reduziert werden, wenn Sie die Anzahl der VMs reduzieren, die den Monitoring-Agent verwenden.

Beispiel: Zur Reduzierung der Messwertvolumen können Sie festlegen, dass Ihrer Entwicklungsumgebung oder anderen für Monitoring unwichtigen Umgebungen keine Google Cloud-Projekte hinzugefügt werden. Darüber hinaus können Sie festlegen, dass der Monitoring Agent nicht in VMs in Entwicklungsumgebungen oder anderen unwichtigen Umgebungen aufgenommen wird.

Nutzung benutzerdefinierter Messwerte reduzieren

Benutzerdefinierte Messwerte sind kostenpflichtig. Sie werden erstellt, wenn mit der Monitoring API von Nutzern instrumentierte Messwerte überwacht werden. Sie können diese Messwerte mithilfe der Monitoring API oder mithilfe von Integrationen erstellen.

Eine solche Integration ist OpenCensus. OpenCensus ist eine Distribution von Bibliotheken, die Messwerte und verteilte Traces aus Ihren Anwendungen erfassen. Mit OpenCensus instrumentierte Anwendungen können Messwerte mithilfe von benutzerdefinierten Messwerten an mehrere Back-Ends, auch Monitoring, melden. Die Messwerte werden in Monitoring unter dem Präfixressourcentyp custom.googleapis.com/opencensus angezeigt. Die von OpenCensus gemeldete Client-Roundtrip-Latenzzeit wird in Monitoring beispielsweise unter dem Ressourcentyp custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency angezeigt.

Je mehr Anwendungen Sie für das Senden von Messwerten instrumentieren, desto mehr benutzerdefinierte Monitoring-Messwerte werden generiert. Wenn Sie das Messwertvolumen reduzieren möchten, können Sie die Anzahl der von Ihrer Anwendung gesendeten benutzerdefinierten Monitoring-Messwerte reduzieren.

Kostenkontrollen für Trace

Zur Optimierung der Trace-Nutzung können Sie die Anzahl der aufgenommenen und gescannten Spans reduzieren. Wenn Sie Ihre Anwendung so instrumentieren, dass Spans an Trace gemeldet werden, nehmen Sie über Sampling einen Anteil des Traffics auf. Sampling ist eine wichtige Komponente eines Tracing-Systems, da es wertvolle Einblicke in die durch Anwendungskomponenten wie RPC-Aufrufe verursachte Latenz ermöglicht. Sampling ist nicht nur Best Practice bei der Nutzung von Trace, sondern kann auch zur Reduzierung des Span-Volumens und dadurch der Kosten beitragen.

OpenCensus-Sampling verwenden

Wenn Sie Trace als Exportziel für OpenCensus-Traces verwenden, können Sie mit der Sampling-Funktion in OpenCensus das Volumen der aufzunehmenden Traces reduzieren.

Beispiel: Ihre beliebte Webanwendung erzielt 5000 Abfragen pro Sekunde. Das Sampling von 5 % des Traffics kann hier bereits ausreichen, um einen aussagekräftigen Überblick zu erhalten. Es müssen nicht 20 % sein. Dies reduziert die Anzahl der in Trace aufgenommenen Spans auf ein Viertel.

Sie können das Sampling in der Konfiguration der Instrumentierung angeben. Dafür verwenden Sie die OpenCensus-Python-Bibliotheken für Trace. Der OpenCensus Python-Exporter bietet zum Beispiel einen ProbabilitySampler, mit dem Sie eine Abtastrate angeben können.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Span-Kontingente der Cloud Trace API verwenden

Mithilfe von Kontingenten können Sie die Nutzung und Kosten von Trace einschränken. Span-Kontingente werden auf der API-spezifischen Kontingentenseite in der Google Cloud Console durchgesetzt.

Wenn Sie ein Kontingent festlegen, das unter dem Standardkontingent für das Produkt liegt, garantieren Sie damit, dass Ihr Projekt dieses spezifische Kontingentlimit nicht überschreitet. Auf diese Weise werden ihre Kosten vorhersehbar. Sie können dieses Kontingent auf der API-spezifischen Kontingentseite überwachen, wie in der folgenden Abbildung dargestellt.

API-spezifische Kontingentseite überwachen

Wenn Sie das Span-Kontingent reduzieren, ist möglicherweise eine Überwachung der Span-Kontingentnutzung sinnvoll. Außerdem sollten Sie in Monitoring eine Benachrichtigungsrichtlinie einrichten, damit Sie informiert werden, wenn sich die Nutzung dem Kontingentlimit nähert. In der Benachrichtigung werden Sie aufgefordert, die Nutzung zu prüfen und die Anwendungen und Entwickler zu identifizieren, die für das hohe Span-Volumen verantwortlich sind. Bei einer Überschreitung des festgelegten Span-Kontingents werden die Spans gelöscht, bis Sie das Kontingent anpassen.

Beispiel: Sie haben ein Span-Kontingent von 50 Millionen Spans. Sie können nun festlegen, dass Sie eine Benachrichtigung erhalten, sobald 80 % des API-Kontingents, also 40 Millionen Spans, aufgebraucht sind. Erstellen Sie entsprechend den Anleitungen unter "Benachrichtigungsrichtlinien verwalten" eine Benachrichtigungsrichtlinie mit den im folgenden Abschnitt angegebenen Details.

  1. Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:
    Zu Monitoring.
  2. Wählen Sie im Navigationsbereich für das Monitoring Benachrichtigungen und dann Richtlinie erstellen aus.
  3. Geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
  4. Klicken Sie auf Bedingung hinzufügen:
    1. Die Einstellungen im Bereich Ziel geben die Ressource und den Messwert an, die überwacht werden sollen. Klicken Sie auf das Textfeld, um ein Menü zu aktivieren, und wählen Sie dann die Ressource global aus.
    2. Klicken Sie auf das Textfeld, um ein Menü zu aktivieren, und wählen Sie dann cloudtrace.googleapis.com/billing/monthly_spans_ingested aus.
    3. Fügen Sie die folgenden Werte für Filter hinzu:
      • Klicken Sie auf project_id und wählen Sie Ihre Google Cloud-Projekt-ID aus.
      • Klicken Sie auf chargeable und wählen Sie dann true aus.
    4. Die Einstellungen im Bereich Konfiguration der Benachrichtigungsrichtlinie geben an, wann die Benachrichtigung ausgelöst wird. Füllen Sie die folgenden Felder aus:
      • Wählen Sie unter Bedingung wird ausgelöst die Option Bei jedem Verstoß aus.
      • Geben Sie als Schwellenwert 40000000 ein.
      • Wählen Sie unter Für den Aktuellsten Wert aus.
    5. Klicken Sie auf Speichern.
  5. Klicken Sie auf Speichern.

    Die von der Richtlinie generierte Benachrichtigung sieht in etwa aus wie im folgenden Beispiel. Sie enthält alle Details zum Projekt, die Richtlinie, die die Generierung der Benachrichtigung ausgelöst hat, und den aktuellen Wert des Messwerts.

Benachrichtigungsdetails

Aufrufe von Drittanbietern optimieren

Ihre Anwendung wird möglicherweise von einer anderen Anwendung aufgerufen. Wenn Ihre Anwendung Spans meldet, kann sich die Anzahl der von Ihrer Anwendung gemeldeten Spans nach dem von der Drittanbieteranwendung eingehenden Traffic richten. Ruft zum Beispiel ein Frontend-Mikrodienst einen Checkout-Mikrodienst auf und beide Mikrodienste haben OpenCensus, ist die Abtastrate für den Traffic mindestens so hoch wie die Frontend-Abtastrate. Wenn Sie wissen, wie die instrumentierten Anwendungen miteinander interagieren, können Sie beurteilen, welche Auswirkung die Anzahl der aufgenommenen Spans hat.

Logging-Export

Sind die Kosten im Zusammenhang mit den Logging-Exporten für Sie ein wichtiger Aspekt, können Sie Ihre Logging-Senke aktualisieren und das Volumen der zu exportierenden Logs mit einem Logging-Filter reduzieren. Logs, die Sie nicht benötigen, können vom Export ausgeschlossen werden.

Beispiel: Eine Anwendung in Ihrer Umgebung wird auf Compute Engine ausgeführt und verwendet Cloud SQL, Cloud Storage und BigQuery. Sie können die generierten Logs hier auf die Logs mit Informationen zu diesen Produkten einschränken. Mit dem folgenden Filter beschränken Sie den Export auf Logs für Cloud Audit Logs, Compute Engine, Cloud Storage, Cloud SQL und BigQuery. Sie können den Filter für eine Logging-Senke verwenden und nur die ausgewählten Logs aufnehmen.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Fazit

Google Cloud Observability bietet die Möglichkeit, Daten zur Produktnutzung aufzurufen. Auf diese Weise können Sie die Details Ihrer Produktnutzung nachvollziehen. und auf dieser Grundlage Nutzung und Kosten der Produkte angemessen optimieren.

Nächste Schritte