Instana
Last updated
Was this helpful?
Last updated
Was this helpful?
Bei diesem Tool handelt es sich um ein Application Performance Monitoring (APM) Tool, das mit den Platzhirschen und konkurriert, aber deutlich günstiger ist.
Bei Instana ist Auto-Detection von neuen Hosts (physikalische Sicht), Services, internen Applikationsstrukturen Strukturen (APIs) und deren Beziehungen zueinander das Guiding Light. Insbesondere in elastischen (und somit sehr dynamischen) Cloud-Deployments ist das eine sehr wichtige Eigenschaft. Instana versucht, die Semantik der Anwendungen zu verstehen, um nicht nur Daten, sondern tatsächlich Informationen und automatisches Alerting zu liefern. Bei diesem Ziel ist jede (hart geforderte) manuelle Intervention (zur expliziten Abbildung dieser Strukturen) aufgrund des elastischen/agilen Umfeld nicht akzeptabel, weil es zum Scheitern verurteilt ist. Maintenance-Free. Hierzu enthält Instana viel Wissen über Technologien (z. B. JPA, Docker, Jenkins), denn das wird bei der Interpretation der Daten und einer adäquaten Darstellung der Informationen (u. a. auch navigierbar) benötigt. Auf diese Weise werden die verschiedenen Layer der Applikation erkannt. Damit ist ein Drill-Down vom Web-Service-Request bis runter zu den dadurch ausgelösten Datanbank-Zugriffen möglich. Tatsächliche Bottlenecks können so nicht nur entdeckt, sondern eine evtl. Lösung zeichnet sich im besten Fall schon ab (z. B. wenn 2000 Datenbank-Calls abgesetzt werden, dann werden scheinbar Datenbankzugriffe in einer Loop-Schleife gemacht ... das skaliert natürlich nicht und muß durch Bulk-Queries ersetzt werden). Datenströme (logische Sicht) werden inkl. der Auslastung dargestellt und ermöglichen somit eine gezielte Analyse der Bottlenecks. Asynchrone Kommunikation durch das System kann dem initiierenden Request zugeordnet werden, so daß letztlich der gesamte Kommunikationsweg untersucht werden kann - und das im Live-System.
Die Root-Cause-Analyse soll von Instana vereinfacht werden - deshalb:
Incidents, werden austomatisch erkannt
dive deep ... überall kann man leicht filtern (Filterwerte werden i. a. automatisch bereitgestellt)
wenn die automatischen Filter nicht ausreichen, dann kann man auch eine Filtersprache verwenden (e. g. entity.selfType:java)
Depp Links werden unterstützt (z. B. in Alert-Notifications), so daß der Kontext sofort ersichtlich ist und zwischen Beteiligten ausgetauscht werden kann
Mit Ansätzen wie der lassen sich auch eigene Lösungen stricken, die allerdings zunächst (vielleicht auch dauerhaft) einen hohen zeitlichen Invest erfordern. Letztlich ist man als Betreiber einer Anwendung aber nicht mit den reinen Daten zufrieden, sondern der Nutzen steht und fällt mit der Möglichkeit, aus diesen Unmengen an Daten tatsächlich Informationen zu gewinnen. Nur dadurch lassen sich Probleme/Bottlenecks in der Anwendung aufdecken und gewinnbringende Verbesserungen umsetzen.
Aus guten Grund wurden Lösungen wie Instana, New Relic, Dynatrace, ... geschaffen, die für teures Geld verkauft werden. Eine Selbstimplementierung kann sich wahrscheinlich nur ein Großunternehmen leisten. Eine Adaption vorhandener Open-Source-Lösungen kann auch zeitaufwendig sein oder gar in die Sackgasse führen.
Aus diesem Grund sind bezahlbare fertige (gut supportete) Lösungen eine gute Sache für bestimmte Firmen. Instana scheint diesen Markt im Auge zu haben.
ein sog. Agent-Prozess (z. B. auch als Docker Container - macht die Nutzung extrem komfortabel) wird auf dem System gestartet ( sehr klein - ca. 50MB Memory) und dann läuft die Auto-Discovery-Maschinerie an
enthält komponentenspezifische Sensoren für (Abtastrate: 1 Sekunde)
Betriebssystem
Java-VM
ganz wichtig: man muß den Java-Prozess NICHT mit einem Java-Agent (auf JVM Level) ausstatten. Stattdessen werden die Daten von einem Port abgegriffen, der von der JVM standardmäßig bereitgestellt wird
Appserver (z. B. Tomcat)
ElasticSearch
...
schickt Daten ans Backend (On-Premise vs. Cloud)
ACHTUNG: die gesendeten Daten lassen sich einschränken - auf diese Weise ist es beispielsweise möglich bei SQL-Queries keine Werte der `WHERE-clauses zu übermitteln, so daß im Instana-UI keine "Geheimnisse" sichtbar sind
Backend (Cloud oder On-Premise)
sammelt die Daten der Agents
basierend auf Cassandra, Kafka, ElasticSearch ... scale-out possible with these technologies
Web-User-Interface
Instana bietet seinen Dienst als Software-as-a-Service (präferiert) aber auch als On-Premise-Lösung an.
Gegen eine Saas-Lösung könnte die Geheimhaltung der Daten sprechen ... per Default versucht Instana keine sensiblen Daten zu loggen (z. B. bei SQL-Queries werden keine gebundenen Parameter mitgeloggt), aber letztlich ist es eine Frage des Vertrauens bzw. einen Nachweis aus Compliance Sicht zu erbringen.
Incidents sind spezielle Events, die mit großer Wahrscheinlichkeit Auswirkungen auf die Edge-Services der Anwendung haben ... das sind Services, die vom Endanwender genutzt werden. Instana nutzt hier die sein ganzes Wissen über kennt die Zusammenhänge der Services/Layer und der verwendeten Technologien, um aus Issues, Changes und Metriken potentielle Incidents zu machen. Die große Stärke ist dabei die Korrelation von Incidents mit Issues, Changes und Metriken. Auf diese Weise liefern Incidents häufig schon die Root-Cause oder liefern zumindest wichtige Informationen, um die Root-Cause schneller zu finden.
Instana mißt verschiedene Indikatoren (Durchsatz, Latenz, Fehlerrate, Ausnutzung) und bietet ab einem bestimmten Threshold automatische Issue-Erzeugung (Auffälligkeiten) und - bei entsprechender Konfiguration - Alerting. Für eine Root-Cause Analyse läßt sich in einer Zeitmaschine reisen (Time-Shift).
Instana ist elastic-Microservice-aware, d. h. gestoppte Knoten stellen noch nicht automatisch ein Incident dar - zunächst ist das mal nur ein Issue dar.
ACHTUNG: da die Abtastrate von einer Sekunde sehr hoch ist, aggregiert Instana die Daten ab einem gewissen Alter, um die Datenmenge zu reduzieren. I. a. geschieht das allerdings so spät, daß man zum Zeitpunkt der Root-Cause-Analyse noch alle Daten unaggregiert zur Verfügung hat.
Beispiel:
Bei meinem allerersten Versuch, Instana zu nutzen, wurde mein Host rot gekennzeichnet in der Instana-UI und mit dem Alert "Low Disk Space" gekennzeichnet. Ein df -h auf meinem lokalen System offenbarte, daß Instana bescheid wußte. GENIAL.
Ausgehend von Changes, Issues und Incidents können Alerts getriggert und an verschiedene Kanäle (sog. Alerting Integrations ... eMail, PagerDuty, Office365, Webhook) definiert werden, so daß man bei extrem kritischen Situationen Benachrichtigungen an externe System verschickt.
Empfehlung: "Don't waste time creating and maintaining health rules" - das macht Instana automatisch (technologieabhängig)
Instana unterstützt Deep-Links, um bei Notifications direkt in den Scope einzutauchen.
Application Perspective ist eine gefilterte Ansicht für selektierte Services/Endpoints - Definition durch den Benutzer (Subset aus Services, Endpoints). Unterschiedliche Rollen (DEV, DEVOPS, SRE) haben unterschiedliche Interessen und sollten sich dementsprechend ad-hoc ihre Application Perspective zusammenstellen können.
Eine Application besteht aus mehreren Services, die wiederum mehrere Endpoints haben können
Alle Requests, die über nicht ausgewählte (= irrelevante, d. h. applikationsfremde) Services/Endpoints getriggert werden, bleiben unberücksichtigt. Bei der Definition einer Application Perspective kann man einfach einen oder mehrere Services selektieren und dann alle Downstream-Services automatisch selektieren lassen.
Das praktische an dieser Application Perspective ist, daß sie automatisch erweitert wird, z. B. wenn ein neuer Service hinzukommt, der zu den Filterkriterien paßt.
Applications werden allerdings nicht nur in der Application Perspective verwendet, sondern eignen sich grundsätzlich als Data Source. So kann man beispielsweise SLI/SLO's und Instana Dashboards auf Applications definieren.
Ein Service hat 1-n Endpoints.
Services und Endpoints automatically discovered
endpoints define the API of a service
automatically discovered types:
BATCH
DATABASE
HTTP
MESSAGING
RPC
services: collection of endpoints
kann verteilt sein ... davon abstrahiert Instana
Instana versucht, den Servicenamen nach technologieabhängigen Algorithmen festzulegen. Die Regeln sind hier dokumentiert, so daß man durch Einhaltung gewisser sinnvoller Konventionen den Namen "selbst" bestimmen kann. Man kann andernfalls auch die environment Variable INSTANA_SERVICE_NAME setzen oder in Instana ein entsprechendes Custom-Mapping definieren (das ist dann aber auf jeder Instana Instanz zu tun :-(
Ein Trace ist der Weg eines Requests durch die Anwendungslandschaft bis zur Antwort. Ein Trace besteht aus 1-n Calls - ein Call ist eine Kommunikation zwischen Diensten. Ein Call besteht aus 1-2 Spans (Entry Span, Intermediate Span, Exit Span). Ein Span ist ein Ausführungsabschnitt innerhalb eines Service.
Hier bekommt man einen sehr guten Überblick, über die Landschaft:
Hosts
Services
Man kann hier
Filtern - über eine Query-Sprache wie entity.service.name:blablubb
man kann auch Freitext versuchen ... z. B. den Service-Namen
Gruppieren nach
Availability Zone
Tags: häufig tagged man die Hosts, Services nach verschiedenen Aspekten (Live/Test/Dev, UI/Middleware/DB, ...)
Unmonitored Hosts haben keine Instana-Agents installiert ... das könnten beispielsweise Third-Party-Services sein, die aus der eigenen Anwendungslandschaft aufgerufen werden und somit beim Tracing involviert sind.
In einem elastischen Microservices Umfeld ist es essentiell, daß neue Services nicht erst aufwendig einkonfiguriert werden müssen. Statdessen leben die Services teilweise nur Minuten oder gar Sekunden.
Instana bietet - ausgehend von einem Services-Aufruf (z. B. Webservice) - einen Drill-Down des gesamten Stack-Traces inkl. Dauer der Requests. Das geht sogar soweit, daß man aus dem Instana-UI in den Java-Code navigieren kann. Awesome :-)
Instana verwendet Traces, um den Weg eines Client-Requests an einen Service und durch die (Microservice-) Anwendungslandschaft zu verfolgen. Auf diese Weise lassen sich einersets ganz fein granulare Daten gewinnen (z. B. welche SQL-Query wurde gegen die Datenbank abgesetzt, wie lange hat das gedauert und wie hoch war die I/O-Rate in der Datenbank) und andererseits grobgranulare Informationen (z. B. wie häufig wurde ein Service aufgerufen?) ableiten.
Instana kommt mit dem Anspruch intelligent genug zu sein, um Probleme ohne konfigurierte Grenzwerte zu erkennen.
Machine lerning algorithms to learn performance patterns.
Allerdings läßt kann man als Application Provider Instana Tips geben oder auch explizit konfigurieren, um bessere Insights zu liefern. Möglichkeiten:
Instana User Interface: Service Mappers
Application Code: Java Annotations
Service Discovery + Interaction Discovery + Zero Configuration ► Maintenance-Free
Die Abtastrate der Sensoren beträgt eine Sekunde, d. h. jede Sekunde werden die Metriken aller beteiligten Komponenten erfaßt und gespeichert.
Instana kommt mit einer Vielzahl komponentenspezifischer Sensoren
Betriebssystem
unterstützte Sprachen: https://www.instana.com/supported-technologies/
unterstützte Technologien: https://www.instana.com/supported-technologies/
so daß immer die relevanten Metriken gezogen und dargestellt werden können. Das geht sogar soweit, daß zu ein ElasticSearch Knoten Metriken auf folgenden Ebenen im direkten Zugriff sind:
Spring-Boot
Docker
Lucene Index
ElastciSearch Shard
ElasticSearch Cluster
Java-VM
OS-Prozess
Host
...
Im UI wird hierzu für jede Ebene spezifische Informationen geliefert. Beispiel:
Bei einer Spring-Boot Anwendung, die in einem Docker-Container auf einem Linux-System läuft, gibt es die folgenden Ebenen und Informationen:
Host: CPU, Betriebssystem, Hostname, Netzwerkschnittstellen, ...
Docker Container: Image, Start-Kommando, Startzeitpunkt, Ports, Container Labels, Scheduler (Docker-Compose, Nomad, ...)
Prozess: Umgebungsvariablen, Startparameter
JVM: Java-Version, Memory-Settings, JVM-Parameter
Spring Boot: Konfiguration
Das ist bei der Fehleranalyse sehr hilfreich.
Zudem werden dadurch, daß Instana diese Technologien kennt, besonders auffällige/ungesunde Werte entdeckt. Das kann zu einem Alert führen.
Ein Beispiel:
bei ElasticSearch können einzelne Knoten gemonitored werden, aber auch ganze Cluster.
Understanding of Patterns of normal behavior by deep learning.
Da Instana Technology-aware ist (d. h. die eingesetzten Technologien kennt) kann es den Nutzer beim Alerting, bei der Root-Cause-Analyse und beim Problem-Solving unterstützen.
Instana plant die Sensorentwicklung offen zu gestalten, so daß man für nicht unterstützte Technologien auch eigene Sensoren schreiben kann.
Es stehen folgende Kategorisierungsmöglichkeiten zur Verfügung:
Tenants
die Daten verschiedener Tenants sind tatsächlich hart getrennt (z. B. Live vs. Dev/Test) ... ein Filter arbeitet ausschließlich auf den Daten EINES Tenants - im Gegensatz zu den anderen Kategorisierungsmöglichkeiten
Zones (entity.zone=myzone)
Tags
ein Services kann mehrere Tags haben, so daß auf verschiedenen Ebenen gefiltert werden kann
Queries über Lucene-Syntax ... per AND verknüpft (OR muss explizit angegeben werden). Hierbei unterstützt Instana auf den Keys (z. B. entity.tag.name) vollständig Auto-Completion, auf den Values aber nur teilweise. Ich wünschte auf den Values würde es besser funktionieren, denn bei entity.severity:10 weiß man natürlich nicht, was die 10 bedeutet ... hier muß man das Datenmodell schon gut kennen.
entity.tag.name:foo=bar
entity.type:springboot
entity.docker.label:maintainer=Pierre
entity.host.cpu.count:<4 AND entity.zone:production) OR entity.host.cpu.count:>4
Im Gegensatz zu On-Premise-Hosting gibt man beim Cloud-Hosting durch Instana die Daten in deren Obhut - ist das sicher?
Instana ist SOX-compliant und sichert zu, daß kein Content in Form von URL-Parametern oder Post-Request-Pasyloads auf den Servern
Instana funktioniert i. a. nur durch Installation des Agent schon sehr gut, doch in manchen Situationen möchte man
nicht unterstützte Technologien verwenden
Metriken mit Daten anreichern
Instana bietet eine REST-API, um die Daten automatisiert in die eigenen Workflows einzubinden. Aber auch, um eigene Informationen über die Instana-Agent-REST-API ins Monitoring zu bekommen, z. B. bei neuen Deployments.
Hierzu benötigt man einen API-Key, den man über die Instana UI im Bereich Access Control erzeugen kann. An diesem API-Key hängen die entsprechenden Berechtigungen.
Im Zusammenhang mit der REST API ist das Konzept des Snapshots relevant:
Alle Bewegungsdaten sind einem Snapshot - die Bewegungsdaten selbst sind allerdings nicht darin gespeichert. Unter Verwendung der Snapshot-Ressource lassen sich auch Dynamic Focus Queries verwenden, um die relevanten Daten besser eingrenzen zu können. Folgende Query
https://tenant-id.instana.io/api/snapshots?q=event.text:version_status
liefert alle SnapshotIDs, die Events mit event.text:version_status enthalten. Fügt man anschließend eine SnapshotID hinzu, so kann man tatsächlich an die Daten kommen:
Den API-Key definiert man am besten auf höchster Ebene (am Instana-Paket) und referenziert ihn in den einzelnen Requests nur mit "Inherit from Parent". Als Key verwendet man authorization, als Value apiToken {{instanaApiToken}} - wobei man die Variable instanaApiToken dann noch definieren und setzen muß.
Das Grafana-Instana-Plugin verwendet die Backend REST API. Es ist Open Source und somit eine guter Blueprint für die Verwendung der Backend-REST-API.
https://www.instana.com/docs/api/agent/#event-sdk-web-service
sorgt für ein Warning Issue im Instana ... schon richtig getaggt (mit den Tags aus dem Instana-Agent). Keine Authentifizierung notwendig.
Man kann per "incident": true auch Incidents statt Issues erzeugen.
Unter Verwendung des path lassen sich Events mehrfach verlängern, um zu verhindern, daß sie als getrennte Events interpretiert werden. Das ist in Fällen interessant bei denen die Abtastrate zu gering ist.
Hintergrund: Instana ist eigentlich auf Metriken ausgelegt, die im Millisekundenbereich abgetastet werden. Bei Events, die evtl. nur alle paar Sekunden abgetastet (= geprüft) werden, würden ansonsten Einzelevents entstehen, obwohl das Problem in der Zwischenzeit nicht weg war.
https://www.instana.com/docs/api/agent/#trace-sdk-web-service
... REST-Calls an den Instana-Agent
Der Instana-Agent kann als Statsd-Proxy konfiguriert werden:
Auf diese Weise kann man Messwerte per echo "pierreinside:30|ms" | nc -u -w1 127.0.0.1 8125 an den Instana-Agent schicken. Die sind dann in der INfrastructure - Dashboard View am Host hängend (und mit den entsprechenden Tags ausgestattet, die im Instana-Agent konfiguriert sind) unter Custom Metrics zu finden:
c: counter - Zähler auf Server-Seite
hier wird nur die Differenz (bei foo:1|c ist die Different 1) mitgeteilt
g: Gauge - Zähler auf Client-Seite
hier wird nur die Differenz (bei foo:1|g ist die Different 1) mitgeteilt
ms: Timer
h: Histogramm
m: Meters
Zur Verarbeitung dieser Messwerte stehen zwei Möglichkeiten zur Verfügung:
Events
aus den Messwerten lassen sich Events erzeugen und aus Events lassen sich Alerts erzeugen
was ist der Unterschied zur Event-API?
bei der Generierung von Events aus Messwerten beobachtet Instana die Messwerte und entscheidet dann irgendwann aus den Daten eine Information zu machen - diese Information ist das Event
Metriken => Event => Alert
Events, die über die Event-API kommen, werden bereits an der Quelle zu einer Information (z. B. es wurde ein neuer Heapdump erzeugt) - Instana muß dann keinen Hirnschmalz investieren
Event => Alert
kann aus dem Kontext bereits ein Event erzeugt werden, dann ist das auf jeden Fall eine höherwertige Information als aus Messwerten (= Metriken = Daten) durch mehr-oder-weniger intelligente Logik eine Information (= Event) zu generieren - die Kontextinformation liefert die besseren Ergebnisse
Grafana-Dashboard
hier werden keine Events unterstützt, sondern nur Metriken
Kann es sein, daß???
Grafana (Reporting/Statistiken ist das Ziel) berücksichtigt ausschließlich Metriken - keine Events
Instana (Alerting ist das Ziel) berücksichtigt ausschließlich Events (deshalb müssen aus Metriken Events gemacht werden) - keine Metriken
Sollte Instana wichtige Strukturen/Zusammenhänge in der Anwendung nicht selbständig erkennen, so lassen sich im Code Metainformationen über Annotationen hinterlegen:
In der Analyze Trace View kann man dann eine Filter sdk.myService.methodExecution definieren, um die Daten zu sehen.
physikalische Sicht auf Hosts, Container, Prozesse
logische Sicht auf Services
Traces - einzelne Messpunkte, die bis in den Code (wird decompiliert) runtergehen
Am einfachsten startet man einen Instana Agent per Docker ... hier die docker-compose.yml:
ACHTUNG: dieser Docker Container zieht beim Start per Maven alle Sensoren vom instana Server (im Log findest sich sowas in der Art:
mvn:com.instana/sensor-java-trace/1.2.248)
BTW:
instana/config/thisIsAnAdditionalConfig.yamlist optional ... man benötigt sie, wenn man Instana Annotation in den Services des Hosts verwendet hat.
Auch wenn Instana den Anspruch von Zero-Configuration hat, sind einiger Konfigurationen sehr sinnvoll und erfolgen in der configuration.yml des Agents:
Meta-Daten ** beispielsweise Identifikation der Umgebung (wenn man mehrere Umgebungen in einem Instana-Account monitored) *** com.instana.plugin.generic.hardware **** availability-zone *** com.instana.plugin.host **** tags
Secrets will man i. a. nicht nach Instana transferieren ** com.instana.secrets
wenn man seinen Java-Code mit dem Instana-SDK angereichert hat ** com.instana.plugin.javatrace *** instrumentation/sdk/packages
Instana ist super ... wenn man ohne großen Aufwand Built-In-Metriken, den Fluß eines Calls durch die Layer und Performance untersuchen will. Das hilft bei der Analyse von Problemen extrem weiter. Mit der Application Perspective lassen sich die Daten auch besser einer Subkomponente zuordnen.
Möchte man allerdings mehr Semantik in die Überwachung integrieren, dann habe ich noch nicht die richtigen Wege gefunden. Wenn man gezieltes End-to-End-Monitoring, das die Integration von Custom-Daten erfordert (ist die Infrastruktur so wie definiert - daß nämlich 3 Instanzen des Srevice A laufen?), fehlen mir die Integrationsmöglichkeiten ... wie bringe ich meine Logik in Instana ein? Muß ich mir einen eigenen Sensor schreiben? Es kommt mir derzeit (mag an fehlendem KnowHow liegen) so vor als sei Instana sehr gut, um die Detail-Analyse durchzuführen ... bei dem Thema End-to-End-Monitoring aber nicht so gut aufgestellt, weil die Integration von Custom-Semantik nicht vorgesehen ist oder (noch) nicht gut unterstützt wird.
Beispiel:
Ich wollte gerne ein Alert erzeugen, wenn eine unserer Services einen Heap-Dump wegen Speichermangel erzeugt. In diesem Fall stehen mir (vom Instana-Support bestätigt) zwei Möglichkeiten zur Verfügung
Instana-Agent Event-API
Instana-Agent Statsd-Proxy für Metriken
In einem solchen Fall erschien mir ein Alert das passende Konzept, da Metriken eine sehr hohe Abtastrate haben (im Sekundenbereich) - mein Heapdump entsteht nur alle paar Stunden, Tage oder sogar Wochen. Die Event-API ist sehr rudimentär was die Bereitstellung von Meta-Daten betrifft. Hier steht eigentlich nur ein Textfeld zur Verfügung, das dann später verwendet werden kann, um einen Filter für das Alerting zu definieren. Ich hätte mir hier eher ein Tagging gewünscht, um gezielter (statt mit String-Wildcards) Selektionen vorzunehmen.
Events haben einen Start und ein Ende ... hat man eine zu geringe Abtastrate beendet Instana ein erstelltes Event selbst. Das führt dazu, daß bei entsprechendem Alerting über Start und Ende informiert wird und die Nitification-Queue vollmüllt, wenn man eine kleinere Abtastrate hat. Man kann sich hier mit einer längeren duration als der Abtastrate behelfen, dann bleibt der Event zumindest für diese Zeit offen und wird dann bei der nächste Abtastung verlängert. Auf diese Weise kann ein Event bei geringer Abtastrate vorm pulieren geschützt werden.
Zudem unterstützt Grafana keine Events und auch SLI/SLO-Dashboards lassen sich nicht auf Basis von Events definieren - ausschließlich Metriken können in den Dashboard-Panels verwendet werden. Meine derzeitige Lösung besteht darin, ein Event und eine Metrik nach Instana zu schreiben ... schon irgendwie redundant.
Frage 1: Welchen Impact hat Instana auf die Performance der Anwendung?
"The first span in a particular service indicates that a call entered the service, and is called an entry span (The Dapper paper refers to it as a “server span”). Spans of calls leaving a service are called exit spans (in the Dapper paper they are “client spans”). Intermediate spans mark significant sections of code so the trace runtime can be clearly attributed to the correct code." ()
Mit dem sog. lassen sich (intermediate) Spans im Applikationscode per Instana-SDK (z. B. ) definieren, um so beispielsweise innerhalb eines Services weitere Zwischenmessungen von Laufzeiten abzubilden.
Hierzu bietet Instana einige (), die wirklich einfach zu nutzen sind und teilweise - wenn man eine Schnittstelle über den Instana-Agent nutzt - nicht einmal Authentifizierung benötigt.
=> praktisch, um sich ein paar Einblicke zu verschaffen
Die . Diese Schnittstellenbeschreibung läßt sich einfach in Postman importieren und dann können komfortabel Requests abgesetzt werden. Alternativ kann man sich aus der REST-OpenAPI per Client-Libs (Java, Go, Python, ...) erzeugen lassen.
Instana läßt sich als Data-Source in Grafana nutzen (siehe )
Der Instana-Agent spricht das mit dem Messwerte (z. B. foo:1|c - foo ist der Metrik-Identfikator, 1 der Wert und c der Metrik-Typ ... hier ein Counter) gesammelt und zu Metriken aggregiert werden.
Folgende werden unterstützt:
Nach dem Start (docker-compose up instana-agent) sollte der Host im auftauchen.
Antwort 1: Java-Anwendungen werden instrumentiert - das dauert ein wenig, ansonsten hat Instana . Natürlich benötigt der Instana-Agent Ressourcen (Memory/Network-I/O).
