Endpunkte
Endpunkte definieren die API eines Service und stellen eine differenzierte Sicht dahingehend bereit, welche Operationen von den Services bereitgestellt werden. Jeder Aufruf an einen Service erfolgt auf einem einzelnen Endpunkt. Jeder Endpunkt hat einen einzigen, automatisch ermittelten Typ: BATCH, SHELL, DATABASE, HTTP, MESSAGING, RPC. Wie Dienste können auch Endpunkte aus der Perspektive einer Anwendung betrachtet werden.
Der Endpunkt kann statisch deklariert werden oder auf Aufruftags basieren. (Im Gegensatz zum Service, der normalerweise mithilfe von Infrastrukturtags wie springboot.name bestimmt wird.) Beispielsweise wäre eine Kombination aus {call.http.method} {call.http.path} ein typischer Endpunkt eines HTTP-Service.
Ein weiterer Vorteil der Definition separater Endpunkte für einen Dienst besteht darin, dass Dienste, vor allem bei "Monolithen", viele verschiedene Frameworks und Technologien umfassen können: HTTP /REST-APIs, Datenbankzugriff, Integration von Nachrichtenbussen usw. Durch die Erstellung von Endpunkten für jeden API-Typ und eine eventuelle weitere Untergliederung, z. B. nach Protokolldetails, werden Metriken und Statistiken pro API-Typ erfasst.
Instana ordnet Endpunkte basierend auf Standardregeln automatisch zu. Weitere Informationen finden Sie unter Endpunktzuordnung.
Vordefinierte Regeln
Instana ordnet Endpunkte automatisch auf der Grundlage einer Reihe von vordefinierten Regeln zu. Die folgenden Regeln werden in absteigender Reihenfolge berücksichtigt. Wenn eine Regel zutrifft, wird der entsprechende Endpunkt erstellt.
| Regel | Tags |
|---|---|
| Benutzerdefinierte Endpunktregel | Vom Benutzer definierte Tags (siehe benutzerdefinierte Endpunktzuordnung ) |
| Benutzerdefinierter Endpunktname über HTTP Header | {call.http.header.x-instana-endpoint} |
| Benutzerdefinierter Endpunktname in sdk-Spannendaten | {call.tag.endpoint} |
| OpenTelemetry definierter Name der Operation | {otel.operation} |
| Jaeger definierter Name der Operation | {call.tag.jaeger.operation} |
| Zipkin definierter Name der Operation | {call.tag.zipkin.operation} |
| SOAP-Aktion HTTP Kopfzeile | {call.http.header.soapaction} |
| RPC mit WSDL-Namensräumen | {call.rpc.method-1} |
| RPC | {call.rpc.method} |
| GraphQL | {call.graphql.operationType?} {call.graphql.operationName?} |
| Batch-Quarz-Typ anstelle von Hex-Mustern | {call.batch.jobType} |
| Batch-Quarz-Typ anstelle von Deadline | {call.batch.jobType} |
| Batch Hex mit Präfix | {call.batch.job-1} |
| Batch Quartz Numerischer Suffix | {call.batch.job-1} |
| Spring Batch-Job | {call.batch.job-1} |
| Batch | {call.batch.job} |
| Modell Prisma | {call.database.statement-1} |
| Rückgriff auf das Prisma-Modell | Prisma |
| JDBC geparste Anweisung | {call.database.statement-1} |
| JDBC ergebnis der gespeicherten Prozeduranweisung | {call.database.statement-1} |
| Neo4j geparste Anweisung | {call.database.statement-1} |
| Cassandra geparste Anweisung | {call.database.statement-1} |
| Cosmos non-sql Befehl | {call.database.schema-1} |
| ElasticSearch Mehrere Indizes | {call.database.schema-1} |
| ElasticSearch Einzelner Index | {call.database.schema} |
| ElasticSearch Aktion | {call.database.commandType} |
| ElasticSearch Verschiedene API-Endpunkte | Verschiedene API-Endpunkte |
| MongoDB sammlung aus Abfrage geparst | {call.database.schema-1}.{call.database.statement-2} |
| MongoDB sammlung nicht aus Abfrage analysierbar | {call.database.schema-1} |
| MongoDB sammlung aus dem Namensraum geparst | {call.database.schema} |
| DynamoDB Tabelle | {call.database.schema} |
| Redis befehl | {call.database.statement} |
| AWS-S3-Bucket | {call.database.schema} |
| AWS S3 betrieb | Verschiedene API-Endpunkte |
| GCS-Bucket | {call.database.schema} |
| GCS-Operation | Verschiedene API-Endpunkte |
| Azure Lagercontainer | {call.database.schema} |
| Azure Speicherbetrieb | Verschiedene API-Endpunkte |
| Memcache / Memcached / EhCache Betrieb | {call.database.commandType} |
| Couchbase eimer | {call.database.schema} |
| Datenraster-Cache | {call.database.schema} |
| Couchbase geparste Anweisung | {call.database.statement-1} |
| Aerospike-Erklärung | {call.database.statement} |
| IMS DB mit Anweisung | {call.database.statement} |
| IMS DB ohne Anweisung | IMS DB |
| datenbank-Fallback | {call.database.commandType} |
| Temporäre Warteschlangen für Nachrichten | temporäre Warteschlange |
| IBM MQ spanne über Adresse | {call.messaging.address-1} |
| IBM ACE-Spanne mit Adresse | {call.messaging.address-1} |
| Messaging Standardaustausch für AzureQueue | {call.messaging.exchangeType} |
| Apache RocketMQ spanne über Adresse | {call.messaging.address-1} |
| Nachrichtenübermittlung generisch | {call.messaging.address} |
| Messaging Standardaustausch für RabbitMQ | standardaustausch |
| Temporäre Warteschlangen für Nachrichten | temporäre Warteschlange |
| z/OS API verbinden | {call.zcee.apiName} |
| HTTP mit Pfadvorlage | {call.http.method?} /{call.http.pathTemplate-1} |
| HTTP mit Routen-ID | {call.http.routeId} |
| Erstes HTTP Pfadsegment nach der API-Version, falls vorhanden | {call.http.method?} {call.http.path-1} |
| HTTP Methode mit Wurzelpfad | {call.http.method} / |
| HTTP Wurzelpfad | {call.http.method?} / |
| Ereignis allgemein | {call.event.source} |
| Abrufen des Shell-Binärnamens ohne Argumente und des Skriptnamens ohne Argumente | {call.shell.command-1} {call.shell.command-2} |
| Shell-Binärnamen ohne Argumente abrufen | {call.shell.command} |
| Funktion als Dienst mit Name und Version | {faas.functionname}:{faas.functionversion} |
| Funktion als Dienst nur mit Namen | {faas.functionname} |
| Funktion als Dienst mit Kennung | {cloud.id} |
| SDK.name | {call.sdk.name} |
Endpunktzuordnung
Endpunkte werden basierend auf dem Endpunkttyp automatisch zugeordnet.
Instana gruppiert beispielsweise auf der Pfadvorlage basierende HTTP-Endpunkte automatisch, wenn auf diese zugegriffen werden kann.
/hospital/1948/patient/291148
/hospital/728/patient/924892
/hospital/47/patient/25978
/hospital/108429/patient/1847
Im vorangehenden Beispiel werden die vorangehenden Endpunkte, die vom gleichen Anwendungscode bedient werden und daher ein gemeinsames Leistungsprofil haben, gruppiert und wie folgt gemeldet:
/hospital/{hid}/patient/{pid}
Dies geschieht automatisch, und für bekannte Frameworks sind keine Benutzerschritte erforderlich.
Wenn die Pfadvorlage nicht verfügbar ist, werden die Endpunkte auf das erste Pfadsegment abgebildet oder können nach Wunsch konfiguriert werden.
Hier sind einige Beispiele, wenn die Pfadvorlage nicht verfügbar ist:
- Im überwachten Dienst werden keine Pfadvorlagen verwendet.
- Tracer unterstützt keine Pfadvorlagen.
- Tracer hat in einigen Fällen, wie z. B. bei fehlgeschlagener Authentifizierung, keinen Zugriff auf die Pfadvorlageninformationen.
- Der Zieldienst wird nicht überwacht und der Exit Span des Clients kennt die Pfadvorlagen nicht.
Wenn Sie Ihren eigenen Ablaufverfolgungscode schreiben, lesen Sie unsere Best Practices zur benutzerdefinierten Ablaufverfolgung, wie Sie die gleichen Ergebnisse erzielen können.
Endpunktzuordnung anpassen
Für jeden Service ermöglicht Instana eine Konfiguration, die steuert, wie die Serviceendpunkte extrahiert werden. Um auf die Konfiguration zuzugreifen, navigieren Sie zu einem Servicedashboard, rufen Sie die Registerkarte zu den Endpunkten auf und klicken Sie auf 'Endpunkte konfigurieren'.
Beachten Sie, dass benutzerdefinierte Endpunktkonfigurationen nur für HTTP -basierte Dienste verfügbar sind.
Angepasste Endpunktregeln
Instana verfügt über drei HTTP-Standardregeln, die immer Teil der Extraktionskette sind:
- Erkanntes Framework: Endpunkte werden entsprechend der Angabe im erkannten Framework extrahiert (falls zugänglich).
- /* : Extrahiert Endpunkte basierend auf dem ersten Pfadparameter.
- Nicht spezifiziert : Anrufe, die keiner vorangegangenen Regel entsprechen, werden diesem Endpunkt zugewiesen.
Wenn Sie eine zusätzliche Konfiguration angeben möchten, können Sie mehrere angepasste Regeln definieren. Rufen Sie dazu das Dialogfeld für die benutzerdefinierte Endpunktkonfiguration von einem beliebigen HTTP -Dienst aus auf, und wählen Sie Benutzerdefinierte Regel hinzufügen HTTP. Der sich öffnende Dialog bietet Ihnen die Möglichkeit, einen bestimmten Pfad (die tatsächliche Regel) und mehrere Testfälle zu definieren, um zu prüfen, ob der definierte Pfad wie erwartet funktioniert. Für den Pfad können Sie statische Segmente wie /api oder /myShopEndpoint, Pfadparameter wie /{productId} oder beliebige Segmente mit /* verwenden.
Im Regeltesterteil des Dialogs können Sie mehrere Testfälle zum Prüfen von Regeln definieren. Wenn beispielsweise eine Abfrage /api/*/{version} gegeben ist, stimmt der Testfall /api/anyName/123 mit dieser überein, während /otherApi/anyName/123 dies nicht tut.
Sequenzielle Evaluation
Die Regeln werden der Reihe nach angewendet, von der ersten bis zur letzten, und die Anrufe werden der ersten passenden Regel zugewiesen. Die Reihenfolge ändern, Regeln einfach neu anordnen, aber nur per Drag & Drop. Instana-Standardregeln können inaktiviert, aber nicht neu geordnet werden.
Synthetische Endpunkte
Endpunkte, die nur synthetischen Datenverkehr empfangen, wie z. B. Aufrufe zum Überprüfen des Status von Endpunkten, können die KPIs Ihrer Anwendungen und Services verzerren. Instana erkennt diese Endpunkte automatisch und kennzeichnet sie als synthetisch, um zu verhindern, dass sie Anwendungs- und Service-KPIs beeinflussen.
Wie synthetische Endpunkte in Instana verwendet werden
Jeder unter einem synthetischen Endpunkt abgelegte Aufruf wird bei unbegrenzter Analyse als synthetisch gekennzeichnet und in Bezug auf die KPIs der Ansichten 'Anwendungsperspektive', 'Service' und 'Endpunkt' nicht gezählt.
Obwohl ihre Aufrufe in Bezug auf KPIs von Anwendungsperspektiven und Services nicht gezählt werden, haben die einzelnen synthetischen Endpunkte genau wie ihre nicht-synthetischen Entsprechungen eigene Dashboards.
Synthetische Standardendpunkte
Synthetische Endpunkte werden standardmäßig durch die folgenden URL-Muster identifiziert:
/healthcheck/health-check/heartbeat/ping/ready/robots.txt(dieser wird von Suchmaschinen zur Indizierung von Websites verwendet)/actuator/health- Zur Abdeckung der Endpunkte von Spring Boot Actuator Health
Sie können die integrierte Regel deaktivieren und benutzerdefinierte Regeln festlegen, um zusätzliche Endpunkte als synthetisch zu kennzeichnen. Weitere Informationen finden Sie in der Dokumentation zu den benutzerdefinierten Regeln für Synthetic-Endpunkte. Die Konfiguration der integrierten und benutzerdefinierten Endpunktregeln wird über die Schaltfläche Dienste konfigurieren in der Liste Dienste aufgerufen.
Angepasste Regeln für synthetische Endpunkte
Zur Unterstützung bei der Konfiguration werden die betroffenen Endpunkte und Services angezeigt.
Synthetische Aufrufe
Es ist neben dem Kennzeichnen aller Endpunkte als synthetisch auch möglich, einzelne Aufrufe so zu kennzeichnen. Dies ist besonders nützlich, wenn Ihre synthetischen Prüfungen 'Produktions-APIs' verwenden, was im Allgemeinen eine ausgezeichnete Idee ist.
Regeln für synthetische Aufrufe
Ein Aufruf wird in Instana als synthetisch gekennzeichnet, wenn eine oder mehrere der folgenden Bedingungen erfüllt sind:
Er gehört zu einem Synthetischen Endpunkt
Er ist eine HTTP-Anforderung mit dem HTTP-Header
X-INSTANA-SYNTHETIC: 1.Es handelt sich um eine HTTP Anfrage, die einen der folgenden User Agents enthält:
kube-probe, was der Wert vonUser-AgentHeader für von Kubernetes ausgegebene Probesdiego-healthcheckist der Wert desUser-AgentHeaders für Healthchecks, die von Diego, dem Scheduler von Cloud Foundry in neueren Versionen von Cloud FoundryELB-HealthChecker, was einen Teil des Wertes desUser-AgentHeader für von AWS Elastic Load Balancer ausgegebene Healthchecks
Anders als im Fall
X-INSTANA-SYNTHETICerfasst Instana nicht standardmäßig die KopfzeileUser-Agent.Damit diese Regeln angewendet werden können, müssen Sie die Funktion Custom HTTP Headers verwenden, damit die Host-Agenten, die Ihre APIs überwachen, den
User-AgentHeader erfassen.Es handelt sich um eine Spring Cloud Consul Config Watch Aufgabe
Mit
syntheticannotierte Bereiche mit dem Werttrue, der mit jedem der Instana-SDKs für die Ablaufverfolgung erreicht werden kann.
Synthetische Aufrufe bei unbegrenzter Analyse
Synthetische Aufrufe werden standardmäßig bei unbegrenzter Analyse ausgeblendet, da sie für die Leistungsanalyse nur dann interessant sind, wenn schwerwiegende Fehler auftreten. Damit bei unbegrenzter Analyse auch synthetische Aufrufe abgefragt werden, müssen Sie sie über den Switch Ausgeblendete Aufrufe -> Synthetische Aufrufe einblenden.
Nicht angegebene Endpunkte
Wenn keine ausreichenden Informationen zur automatischen Zuordnung eines Aufrufs zu einem Endpunkt vorhanden sind (z. B. manuell instrumentierte Endpunkte ohne Angabe von ausreichenden Daten), werden diese Aufrufe dem besonderen Endpunkt 'Nicht angegeben' zugeordnet.
Andere Endpunkte
Wenn für einen bestimmten Service zu viele Endpunkte erkannt werden, werden Aufrufe unter dem besonderen Endpunkt 'Andere' gruppiert. Diese Absicherung ist dazu gedacht, die Gruppe der Endpunkte in einer angemessenen Größe zu halten.
Dies geschieht in der Regel, wenn eine der vordefinierten Regeln von Instana oder eine benutzerdefinierte Regel Anrufe in einer großen Anzahl von Endpunkten gruppiert, die jeweils einen einzigen Anruf erhalten haben.
Eine der vordefinierten Regeln von Instana ist zum Beispiel die Zuordnung von HTTP -Aufrufen zu Endpunkten, deren Namen aus dem ersten Pfadsegment in URL stammen. Wenn diese Segmente aus dynamischen Werten gebildet werden (z. B. "GET /blue-item", "GET /red-item"...), die Anwendung dieser Regel würde zu einer hohen Anzahl von Endpunkten führen, was nicht sinnvoll ist.
Beim Umgang mit HTTP Endpunkten kann die Situation verbessert werden, indem die Konfiguration der Endpunktextraktionsregeln geändert wird.
Interne Triggerendpunkte
Traces, die von Instana automatisch erfasst werden, beginnen in der Regel mit einem eingehenden Aufruf an einen Service. Wenn das Instana SDK verwendet wird, ist es jedoch möglich, einen Trace mit einem ausgehenden Anruf von einem Dienst zu starten. In diesem Fall erstellt Instana einen synthetischen übergeordneten Aufruf (der dem Endpunkt 'Interner Trigger' zugeordnet ist) zu diesem Service, um die Lesbarkeit zu verbessern.
Endpunkt-Ablaufplan
Die Endpunktflusskarte zeigt die vor- und nachgelagerten Endpunkte eines Endpunkts an.
Begrenzung der Endpunkt-Flowmap
Die Endpunktflusskarte zeigt genaue Daten derzeit nur für kurz laufende synchrone Ableitungen, die innerhalb von 20 Sekunden enden. In allen anderen Fällen kann die Endpunktflusskarte ungenaue Daten anzeigen.