Profilazione delle applicazioni Go

In questa pagina viene descritto come modificare l'applicazione Go per acquisire profilazione dei dati e l'invio di questi dati al tuo account Google Cloud progetto. Per informazioni generali sulla profilazione, consulta Concetti di profilazione.

Tipi di profilo per Go:

  • Tempo CPU
  • Heap
  • Heap allocato
  • Conflitto (disattiva mutex)
  • Thread (Goroutine)

Versioni in lingua Go supportate:

Versioni dell'agente di profilazione supportate:

  • È supportata la release più recente dell'agente. In generale, le release meno recenti oltre un anno non sono supportate. Ti consigliamo di utilizzare una versione rilasciata di recente dell'agente.

Sistemi operativi supportati:

  • Linux. La profilazione delle applicazioni Go è supportata per i kernel Linux la cui libreria C standard è implementata con glibc o con musl. Per per la configurazione specifiche dei kernel alpini di Linux, vedi In esecuzione su Linux Alps.

Ambienti supportati:

Abilitazione dell'API Profiler

Prima di utilizzare l'agente di profilazione, assicurati che l'elemento sottostante L'API Profiler è abilitata. Puoi controllare lo stato dell'API e abilitare e, se necessario, utilizzando Google Cloud CLI la console Google Cloud:

Interfaccia a riga di comando gcloud

  1. Se non hai già installato Google Cloud CLI sul tuo consulta la documentazione di Google Cloud CLI.

  2. Esegui questo comando:

    gcloud services enable cloudprofiler.googleapis.com
    

Per ulteriori informazioni, vedi gcloud services.

Console Google Cloud

  1. Attiva l'API richiesta.

    Abilita l'API

  2. Se viene visualizzato API abilitata, l'API è già abilitata. In caso contrario, fai clic sul pulsante Attiva.

Utilizzo di Cloud Profiler

In tutti gli ambienti supportati, il profiler viene utilizzato importando il pacchetto nell'applicazione e inizializzando Profiler il prima possibile nella tua applicazione.

Puoi attivare la profilazione della contesa di Silentx ("Contesa" nel interfaccia) impostando l'opzione di configurazione MutexProfiling su true.

Per ulteriori informazioni sull'API Profiler, incluse tutte le di configurazione, consulta le documenti relativi all'API pubblica.

Compute Engine

Per Compute Engine, in profiler.Config imposta Service con un nome del servizio da profilare e, facoltativamente, impostare ServiceVersion con la versione del servizio:


// snippets is an example of starting cloud.google.com/go/profiler.
package main

import (
	"cloud.google.com/go/profiler"
)

func main() {
	cfg := profiler.Config{
		Service:        "myservice",
		ServiceVersion: "1.0.0",
		// ProjectID must be set if not running on GCP.
		// ProjectID: "my-project",

		// For OpenCensus users:
		// To see Profiler agent spans in APM backend,
		// set EnableOCTelemetry to true
		// EnableOCTelemetry: true,
	}

	// Profiler initialization, best done as early as possible.
	if err := profiler.Start(cfg); err != nil {
		// TODO: Handle error.
	}
}

Se nel codice sorgente sono presenti dipendenze recuperate manualmente, potresti dover aggiungere quanto segue script di build o Dockerfile:

go get cloud.google.com/go/profiler

GKE

Per GKE, in profiler.Config imposta Service con un nome del servizio da profilare e, facoltativamente, impostare ServiceVersion con la versione del servizio:


// snippets is an example of starting cloud.google.com/go/profiler.
package main

import (
	"cloud.google.com/go/profiler"
)

func main() {
	cfg := profiler.Config{
		Service:        "myservice",
		ServiceVersion: "1.0.0",
		// ProjectID must be set if not running on GCP.
		// ProjectID: "my-project",

		// For OpenCensus users:
		// To see Profiler agent spans in APM backend,
		// set EnableOCTelemetry to true
		// EnableOCTelemetry: true,
	}

	// Profiler initialization, best done as early as possible.
	if err := profiler.Start(cfg); err != nil {
		// TODO: Handle error.
	}
}

Se nel codice sorgente sono presenti dipendenze recuperate manualmente, potresti dover aggiungere quanto segue script di build o Dockerfile:

go get cloud.google.com/go/profiler

App Engine

Per l'ambiente flessibile di App Engine e per App Engine nell'ambiente standard, le aggiunte di codice identiche a quelle di Compute Engine e GKE. C'è una sola eccezione. In entrambi gli ambienti App Engine, Service e ServiceVersion vengono derivati dall'ambiente, per cui non è necessario e specificarli.


// appengine is an example of starting cloud.google.com/go/profiler on
// App Engine.
package main

import (
	"cloud.google.com/go/profiler"
)

func main() {
	// Profiler initialization, best done as early as possible.
	if err := profiler.Start(profiler.Config{
		// Service and ServiceVersion can be automatically inferred when running
		// on App Engine.
		// ProjectID must be set if not running on GCP.
		// ProjectID: "my-project",
	}); err != nil {
		// TODO: Handle error.
	}
}

Quando esegui l'applicazione in locale, imposta ProjectID (l'ID del progetto Google Cloud) e i parametri Service in profiler.Config, poiché non possono essere derivati da un ambiente locale. Non è necessario impostare ServiceVersion.

Se utilizzi l'ambiente standard di App Engine, consulta Eseguire la migrazione dell'app a Go 1.11 per avere informazioni dettagliate su come le modifiche che potresti dover apportare alla tua applicazione. Inoltre, devi utilizzare Google Cloud CLI versione 226.0.0 o successive. Per aggiornare Google Cloud CLI, esegui seguente comando:

    gcloud components update

Per eseguire l'applicazione:

  1. Aggiorna le dipendenze:

    go get cloud.google.com/go/profiler
    
  2. Esegui il deployment dell'applicazione nell'ambiente flessibile di App Engine oppure l'ambiente standard di App Engine:

    gcloud app deploy [DEPLOYMENT]
    

    dove DEPLOYMENT è il percorso del file di configurazione. Ad esempio: DEPLOYMENT potrebbe essere main/app.yaml.

Analisi dei dati

Dopo che Profiler ha raccolto i dati, puoi visualizzare e analizzare questi dati utilizzando l'interfaccia Profiler.

Nella console Google Cloud, vai alla pagina Profiler:

Vai a Profiler

Puoi trovare questa pagina anche utilizzando la barra di ricerca.

Argomenti per nome e versione del servizio

Quando carichi l'agente Profiler, specifichi un argomento service-name e un un argomento facoltativo service-version per configurarlo.

Il nome del servizio consente a Profiler di raccogliere dati di profilazione per tutti di repliche di quel servizio. Il servizio profiler garantisce tasso di raccolta di un profilo al minuto, in media, per ogni servizio in ogni combinazione di versioni e zone del servizio.

Ad esempio, se hai un servizio con due versioni in esecuzione di repliche in tre zone, il profiler creerà una media di 6 profili al minuto per quel servizio.

Se utilizzi nomi di servizio diversi per le repliche, il servizio essere profilati più spesso del necessario, con un overhead di conseguenza più elevato.

Quando selezioni il nome di un servizio:

  • Scegli un nome che rappresenti chiaramente il servizio nella tua applicazione dell'architettura. La scelta del nome del servizio è meno importante se esegui solo un singolo servizio o una singola applicazione. È più importante che la tua applicazione viene eseguito come un insieme di microservizi, ad esempio.

  • Assicurati di non utilizzare valori specifici per il processo, ad esempio un ID processo, nella stringa service-name.

  • La stringa del nome del servizio deve corrispondere a questa espressione regolare:

    ^[a-z0-9]([-a-z0-9_.]{0,253}[a-z0-9])?$

Una buona linea guida è usare una stringa statica come imageproc-service come il nome del servizio.

La versione del servizio è facoltativa. Se specifichi la versione del servizio, Profiler può aggregare le informazioni di profilazione da più le istanze VM e visualizzarle correttamente. Può essere usato per contrassegnare versioni diverse dei servizi durante il loro deployment. La UI di Profiler ti consente filtrare i dati in base alla versione del servizio; In questo modo, puoi confrontare il rendimento delle versioni più vecchie e più recenti del codice.

Il valore dell'argomento service-version è una stringa in formato libero, ma valori per questo argomento generalmente sono i numeri di versione, ad esempio 1.0.0 o 2.1.2.

Logging agente

L'agente di profilazione può segnalare le informazioni di debug nei propri log. Per impostazione predefinita, il logging degli agenti è disabilitato.

Per abilitare il logging dell'agente, Imposta l'opzione DebugLogging su true all'avvio dell'agente:

profiler.Start(profiler.Config{..., DebugLogging: true});

Risoluzione dei problemi

Questa sezione elenca i problemi specifici della profilazione delle applicazioni Go. Consulta la sezione Risoluzione dei problemi. per ricevere assistenza in merito a problemi comuni.

Comportamento Causa Soluzione
I profili di tempo CPU non vengono raccolti per le applicazioni create con -buildmode=c-archive. heap, contese vengono raccolti i profili dei thread. Problema GitHub Per impostazione predefinita, la profilazione della CPU non è abilitata per le applicazioni Go quando Il flag -buildmode è c-archive o c-shared. Aggiungi una chiamata a
signal.Notify(make(
chan os.Signal), syscall.SIGPROF)
prima di chiamare profiler.Start.
Risposta al problema su GitHub.

Esecuzione con Linux alpino

L'agente di profilazione Go per Linux Alps è supportato solo per configurazioni di Google Kubernetes Engine.

Errore di autenticazione

Se utilizzi immagini Docker eseguite con Linux alpino (ad es. golang:alpine o solo alpine), potrebbe essere visualizzato il seguente errore di autenticazione:

connection error: desc = "transport: authentication handshake failed: x509: failed to load system roots and no roots provided"

Tieni presente che, per visualizzare l'errore, devi avere abilitato il logging dell'agente. Per impostazione predefinita, l'agente per Go non restituisce alcun messaggio di log.

L'errore indica che le immagini Docker con Linux Alpine non hanno certificati SSL radice installati per impostazione predefinita. Questi certificati sono necessari per l'agente di profilazione per comunicare con l'API profiler. Da risolvere questo errore, aggiungi il seguente comando apk al tuo Dockerfile:

FROM alpine
...
RUN apk add --no-cache ca-certificates

Devi quindi ricreare la build ed eseguire nuovamente il deployment dell'applicazione.

Passaggi successivi