Kontinuierliches Profiling

Kontinuierliches Profiling zeigt, wofür Ihre Anwendung CPU-Zeit und Arbeitsspeicher verwendet, Funktion für Funktion. Status200 bietet eine Pyroscope-kompatible Ingest-API: Alles, was an einen Pyroscope-Server senden kann – der eBPF-Profiler von Grafana Alloy oder ein Pyroscope-SDK für Ihre Sprache –, kann auch an Status200 senden, und Sie lesen das Ergebnis als Flame-Graphs neben Ihren Protokollen, Metriken und Traces.

So funktioniert es#

Ein Profiler tastet Ihre Prozesse ab und lädt alle paar Sekunden ein Profil mit Ihrem Ingestion-Schlüssel an den Endpunkt /pyroscope von Status200 hoch. Status200 speichert jedes Profil unter dem Dienst, den es nennt, und zeichnet es unter Leistungsprofile als Flame-Graph.

Bevor Sie beginnen#

Sie brauchen einen Telemetrie-Ingestion-Schlüssel vom Typ Server. Falls Sie noch keinen haben:

1. Die Ingestion-Schlüssel öffnen#

   Gehen Sie zu Produkte → Projekteinstellungen, öffnen Sie im Seitenmenü Telemetrie & APM und wählen Sie Ingestion-Schlüssel.

   

2. Einen Schlüssel erstellen#

   Klicken Sie auf Aufnahmeschlüssel erstellen. Im Dialog ist der Name des Schlüssels bereits ausgefüllt und Server gewählt – die Art Schlüssel, mit der eine Anwendung oder ein Collector sendet –; klicken Sie also auf Aufnahmeschlüssel erstellen, um ihn anzulegen, oder benennen Sie ihn vorher um.

3. Das Geheimnis kopieren#

   Der neue Schlüssel öffnet sich auf seiner eigenen Seite. Kopieren Sie seinen Geheimer Schlüssel: Das ist das Ingestion-Token, das die Beispiele unten YOUR_STATUS200_INGESTION_TOKEN nennen.

   

Ingest-Endpunkt#

Clients hängen ihren eigenen Pfad an die Basis-URL an – /ingest bei den meisten Pyroscope-SDKs, /push.v1.PusherService/Push bei Grafana Alloy und beim .NET-SDK ab v0.14 –, Sie konfigurieren also immer nur die Basis-URL, ohne abschließenden Schrägstrich.

Status200 liest das Ingestion-Token aus jeder dieser Quellen; verwenden Sie, was Ihr Client unterstützt:

Unterstützte Profilformate#

Profile senden#

Grafana Alloy profiliert jeden Prozess auf einem Host ohne Codeänderungen und ist der empfohlene Einstieg. Ein Pyroscope-SDK läuft stattdessen in Ihrer Anwendung.

discovery.process "all" {
  refresh_interval = "60s"
}

discovery.relabel "alloy_profiles" {
  targets = discovery.process.all.targets

  rule {
    action       = "replace"
    source_labels = ["__meta_process_exe"]
    target_label  = "service_name"
  }
}

pyroscope.ebpf "default" {
  targets    = discovery.relabel.alloy_profiles.output
  forward_to = [pyroscope.write.status200.receiver]

  collect_interval = "15s"
  sample_rate      = 97
}

pyroscope.write "oneuptime" {
  endpoint {
    url = "https://status200.ru/pyroscope"
    headers = {
      "x-status200-token" = "YOUR_STATUS200_INGESTION_TOKEN",
    }
  }
}

services:
  alloy:
    image: grafana/alloy:latest
    privileged: true
    pid: host
    volumes:
      - ./alloy-config.alloy:/etc/alloy/config.alloy
      - /proc:/proc:ro
      - /sys:/sys:ro
    command:
      - run
      - /etc/alloy/config.alloy

alloy run alloy-config.alloy

import "github.com/grafana/pyroscope-go"

pyroscope.Start(pyroscope.Config{
    ApplicationName: "my-service",
    ServerAddress:   "https://status200.ru/pyroscope",
    AuthToken:       "YOUR_STATUS200_INGESTION_TOKEN",
    ProfileTypes: []pyroscope.ProfileType{
        pyroscope.ProfileCPU,
        pyroscope.ProfileAllocObjects,
        pyroscope.ProfileAllocSpace,
        pyroscope.ProfileInuseObjects,
        pyroscope.ProfileInuseSpace,
        pyroscope.ProfileGoroutines,
    },
})

const Pyroscope = require("@pyroscope/nodejs");

Pyroscope.init({
  serverAddress: "https://status200.ru/pyroscope",
  appName: "my-service",
  authToken: "YOUR_STATUS200_INGESTION_TOKEN",
});

Pyroscope.start();

import pyroscope

pyroscope.configure(
    application_name="my-service",
    server_address="https://status200.ru/pyroscope",
    auth_token="YOUR_STATUS200_INGESTION_TOKEN",
)

FROM alpine:3.20 AS pyroscope-profiler
ARG PYROSCOPE_DOTNET_VERSION=1.5.1
ADD https://github.com/grafana/pyroscope-dotnet/releases/download/pyroscope-${PYROSCOPE_DOTNET_VERSION}/pyroscope.${PYROSCOPE_DOTNET_VERSION}-glibc-x86_64.tar.gz /tmp/pyroscope.tar.gz
RUN mkdir -p /pyroscope && tar -xzf /tmp/pyroscope.tar.gz -C /pyroscope

FROM mcr.microsoft.com/dotnet/aspnet:10.0
# ... your application ...
COPY --from=pyroscope-profiler /pyroscope /pyroscope
ENV CORECLR_ENABLE_PROFILING=1
ENV CORECLR_PROFILER={BD1A650D-AC5D-4896-B64F-D6FA25D6B26A}
ENV CORECLR_PROFILER_PATH=/pyroscope/Pyroscope.Profiler.Native.so
ENV LD_PRELOAD=/pyroscope/Pyroscope.Linux.ApiWrapper.x64.so
ENV LD_LIBRARY_PATH=/pyroscope

PYROSCOPE_APPLICATION_NAME=my-service
PYROSCOPE_PROFILING_ENABLED=1
PYROSCOPE_SERVER_ADDRESS=https://status200.ru/pyroscope
PYROSCOPE_BASIC_AUTH_USER=oneuptime
PYROSCOPE_BASIC_AUTH_PASSWORD=YOUR_STATUS200_INGESTION_TOKEN

Ruby und Rust funktionieren wie Go, Node.js und Python: Installieren Sie das Pyroscope-SDK für Ihre Sprache und setzen Sie die Serveradresse auf https://status200.ru/pyroscope mit Ihrem Ingestion-Token als Auth-Token (oder, wenn Ihre SDK-Version nur Basic-Auth anbietet, als Basic-Auth-Passwort).

Unterstützte Profiltypen#

Ein pprof kann mehrere Sample-Typen deklarieren; jedes hochgeladene Profil wird unter einem davon gespeichert – CPU-Zeit (cpu in Nanosekunden), wenn vorhanden, sonst Wall-Time, sonst belegte und danach allozierte Bytes, sonst der erste deklarierte Typ. Jeder Typ wird gespeichert und ist sichtbar; die folgenden Typen bekommen in Status200 eigene Gruppierung, Einheiten und Bezeichnungen:

Alles andere (zum Beispiel ein eigener Sample-Typ) erscheint unter „Sonstige“ mit seinem Rohnamen.

Prüfen, ob es funktioniert#

1. Ihr Token prüfen#

   Die Ingest-Endpunkte beantworten ein fehlendes oder ungültiges Token mit 401, doch die meisten Profiler zeigen das nirgends an, wo Sie es sehen (der .NET-Profiler etwa protokolliert HTTP-Antworten nur auf Debug-Ebene). Fragen Sie direkt den Validierungsendpunkt:

   Bash

   curl -i -H "x-status200-token: YOUR_STATUS200_INGESTION_TOKEN" \
     https://status200.ru/otlp/v1/validate

   Ein gültiges Token liefert 200 mit {"valid": true, ...}, und sein keyType muss Server sein: Ein Browser-Schlüssel ist ebenfalls gültig, kann aber keine Profile senden. Ein unbekanntes, widerrufenes, deaktiviertes oder abgelaufenes Token liefert 401.

2. Die Profilseite öffnen#

   Gehen Sie im Status200-Dashboard zu Produkte → Performance-Profile. Mit dem Erfassungsintervall von Alloy von 15 Sekunden (oder dem Upload-Intervall der SDKs von 10 bis 15 Sekunden) erscheinen die ersten Profile und ihre Flame-Graphs innerhalb von ein, zwei Minuten nach dem Start des Agents.

3. Den Dienst prüfen#

   Profile werden dem Telemetriedienst zugeordnet, den application_name / appName / PYROSCOPE_APPLICATION_NAME des SDKs nennt (oder unter der Relabel-Regel von Alloy oben der Name der ausführbaren Datei des Prozesses).

4. Immer noch nichts? Den Upload-Status ansehen#

   Setzen Sie beim .NET-Profiler für eine Minute DD_TRACE_DEBUG=1 in der Anwendung: Dann protokolliert er für jeden Upload eine Zeile PyroscopePprofSink <status>. 200 heißt, dass Status200 ihn angenommen hat; 401 ist das Token; 404 bedeutet meist, dass PYROSCOPE_SERVER_ADDRESS das Suffix /pyroscope fehlt; 413 bedeutet, dass ein Proxy vor Status200 den Upload wegen seiner Größe abgelehnt hat (siehe Tab .NET unter Profile senden). Wenn Sie Status200 selbst betreiben, verzeichnet das Zugriffsprotokoll des Ingress (nginx) denselben Status für jede Anfrage an /pyroscope.

Profile in Status200 erkunden#

Produkte → Performance-Profile öffnet den Profiler auf seiner Übersicht. Er antwortet in Worten, bevor ein Diagramm kommt: wohin die Zeit geht („Bei checkout entfielen 42% der CPU-Zeit auf JSON.parse.“) und, wenn die meistbeschäftigte Funktion zu einer Bibliothek oder zur Laufzeit gehört, welche Funktion Ihres eigenen Codes am meisten beansprucht, mit dem Bibliotheks- und Laufzeitcode, den sie aufruft. Wählen Sie oben einen Dienst, eine Profilart, für die er Daten hat (CPU-Zeit, Echtzeit, Arbeitsspeicher, Allokationen, Sperren oder Goroutines, oder einen Typ unter Weitere Profiltypen), und ein Zeitfenster.

Zwei Zeitfenster vergleichen#

Vergleichen mit legt fest, womit das Zeitfenster verglichen wird: Der Zeitraum davor, Dieselbe Zeit gestern, Dieselbe Zeit letzte Woche oder ein Deployment unter Vor und nach einer Änderung. Verglichen werden Anteile statt Summen, sodass mehr Traffic allein nichts verschiebt. Die Überschrift nennt die Funktion, deren Anteil am stärksten gewachsen ist, und den eigenen Code, der gewachsen ist; der Flame-Graph wird zu Was sich geändert hat, wo rote Frames danach einen größeren Anteil haben und grüne einen kleineren; und Veränderte Funktionen listet den Anteil jeder Funktion vorher und nachher.

Eine Funktion#

Klicken Sie auf eine Funktion, um ihr Panel zu öffnen: ihren Anteil als Eigen, Gesamt und Ihr Code, Wer sie aufruft und Was sie aufruft, einen Link zu ihrer Datei und Zeile in Ihrem Repository, wenn eines verbunden ist, und Im Flame-Graph hervorheben. Bei einer Funktion einer Bibliothek oder der Laufzeit nennt das Panel die Funktion Ihres eigenen Codes, die sie aufruft, denn dort kann eine Änderung sie günstiger machen. Ein Link unter den Anteilen richtet eine Warnung zum Anteil der Funktion ein, über dem, was sie heute beansprucht: siehe Profile-Überwachung.

Wenn eine Funktion Ihres eigenen Codes mindestens 5 % der Zeit oder des Speichers des Profils beansprucht oder ihr Anteil seit dem Vergleichsfenster um 3 Punkte oder mehr gewachsen ist, bietet das Panel Mit KI beheben an: Status200 AI startet eine Aufgabe in dem Repository, das die Funktion enthält, mit dem Profil als Beleg, und öffnet einen Pull Request, den Sie prüfen (siehe Code). Status200 AI liest Profile auch in seinen Antworten und Untersuchungen, Sie können also fragen, welche Funktionen die meiste CPU-Zeit verbrauchen.

Ein einzelnes Profil#

Alle Profile listet jeden Upload. Die Seite eines Profils hat drei Ansichten:

Download pprof speichert das Profil für lokale Werkzeuge wie go tool pprof.

Trace-Korrelation#

Wenn ein Profil Trace- und Span-IDs trägt (zum Beispiel als Sample-Labels trace_id / span_id), springen Sie direkt von einem langsamen Trace-Span zum passenden CPU- oder Speicherprofil, um genau zu verstehen, welcher Code lief, und Open linked trace führt in die andere Richtung.

Der Tab Profil eines Spans enthält auch die Samples der darunter verschachtelten Spans, weil Profiler die CPU-Zeit einer Anfrage oft einem Kind-Span statt dem Anfrage-Span selbst zuordnen.

Die Seite eines Traces verlinkt außerdem auf den Profiler für den Dienst des Traces, für die 15 Minuten davor und danach, wenn dieser Dienst in der Zeit profiliert wurde, und die Seite Leistungsprofile eines Dienstes oder Hosts öffnet den Profiler für diesen Dienst oder Host.

Datenaufbewahrung#

Profile werden so lange aufbewahrt wie die Telemetrie Ihres Projekts: Projekteinstellungen → Telemetrie & APM → Datenaufbewahrung legt die Standardaufbewahrung (Tage) fest, 15 Tage, sofern Sie sie nicht ändern. Daten werden nach Ablauf der Aufbewahrungsfrist automatisch gelöscht. Tarife mit Aufbewahrungs-Überschreibungen können Profile auch länger oder kürzer als andere Telemetrie behalten oder die Aufbewahrung pro Dienst auf der Seite Einstellungen des Dienstes festlegen.

Nächste Schritte#