Probe-Einstellungen ändern

Sie können die Probe-Standardeinstellungen ändern oder deaktivieren oder eine benutzerdefinierte Probe aktivieren, um zusätzliche Klassen zu überwachen.

Probe-Standardeinstellungen ändern oder deaktivieren

Sie können die standardmäßigen Probe-Einstellungen mit der Datei ProbeConfig.acml ändern oder deaktivieren.

Nachdem Sie einen APM-Java-Agent durch Provisioning bereitgestellt haben, ist die Datei ProbeConfig.acml im Verzeichnis oracle-apm-agent/config verfügbar. Informationen zum Zugriff auf die Datei ProbeConfig.acml finden Sie unter APM-Java-Agent durch Provisioning bereitstellen.

Mit der Datei ProbeConfig.acml können Sie:

  • Aktivieren oder deaktivieren Sie bestimmte Probes.
  • Deaktivieren Sie die Überwachung bestimmter Muster von Traces/Spans basierend auf Informationen wie URL, Dateierweiterung usw.
  • Aktivieren Sie die Erfassung zusätzlicher Tags/Dimensionen. Beispiel: Erfassen bestimmter Header und Parameter für die SERVLET-Probe.
  • Bearbeiten Sie den Span-Namen. Beispiel: Bearbeiten der URL für SERVLET- oder HTTP_CLIENT-Probes.
  • Erfassen Sie DB-SQL-Abfrageanweisungen mit mehr als 1.000 Zeichen als Span-Log.

    Um das Logging der gesamten SQL-Abfrageanweisungen im JDBC-Span-Log zu aktivieren oder zu deaktivieren, verwenden Sie den Parameter enable_complete_sql_span_log_jdbc. Dieses Feature ist hilfreich, wenn eine lange SQL-Abfrage mit 1.000 Zeichen abgeschnitten wird. Beispiel: Verwenden Sie : enable_complete_sql_span_log_jdbc: true, um sie zu aktivieren.

  • Erfassen Sie den angemeldeten Benutzernamen.

    Hashed-Benutzernamen werden für die authentifizierten Sitzungen mit der Absicht erfasst, Berichte über die Anzahl der eindeutigen Benutzer zu ermöglichen, ohne personenbezogene Daten (PII) preiszugeben. Möglicherweise muss der Benutzername jedoch im Nur-Text-Format gemeldet werden. Gehen Sie in diesem Fall zum allgemeinen Abschnitt, und legen Sie track_plain_username: true fest.

  • Payloads erfassen.

    Die Payload enthält den Inhalt der HTTP-Anforderung und -Antwort.

    Sie können den vollständigen Ablauf der Anwendungsanforderungen verfolgen und die erfassten Daten zur Analyse an den Trace-Explorer senden, indem Sie die Payload aktivieren.

    Die Payload Capture-Unterstützung umfasst Servlet, JAX-RS-Server, OSB-Proxyservice und OSB Business Service.

    Ab APM-Java-Agent-Version 1.16 werden auch Apache Http Clients (4.x und 5.x), JDK 11+ Http Client, OCI SDK Http Client (2.x und 3.x), Spring Web Client 5.x und OkHttp Clients 2.x und 3.x unterstützt.

    Payload aktivieren: Um HTTP-Anforderungs- und -Antwort-Payloads zu aktivieren, legen Sie die Parameter capture_request_payload und capture_response_payload in der Datei ProbeConfig.acml fest.

    • Um eine Teilmenge der Payload zu erfassen, können xpath/jsonpath/regex-Ausdrücke basierend auf dem Vorgangsnamen angewendet werden.
    • Nachdem sie aktiviert wurde, sind die erfassten Payloads als Dimensionen verfügbar: RequestPayload bzw. ResponsePayload. Die maximale Standardlänge beträgt 1000 Zeichen.
    • Sie können mehrere Dimensionen aus derselben Payload erfassen, indem Sie tag_name zusammen mit dem Ausdruck angeben.
  • Ändern Sie die Modellierung von asynchronen HttpClient-Aufrufen.

    Ab APM-Java-Agent-Version 1.16 stellt ein einzelner Span die ausgehende Anforderung, Wartezeit und den Callback dar.

    Um das vorherige Verhalten früherer Agent-Versionen beizubehalten (einen Span für den ausgehenden Aufruf und einen zweiten für den Callback), ändern Sie den Parameter httpclient_async_one_span im Abschnitt HTTP_CLIENT in der Datei ProbeConfig.acml, und setzen Sie ihn auf false.
    #Enables capturing async client invocations as a single span. No separate callback spans will be reported
    httpclient_async_one_span: false

Das Standardverhalten der Stichprobeneinstellungen kann mit der Datei ProbeConfig.acml aus dem APM-Java-Agent aktualisiert werden.

Um Änderungen an den standardmäßigen Probe-Einstellungen vorzunehmen, befolgen Sie die Anweisungen in der Datei ProbeConfig.acml.

Änderungen an der Datei ProbeConfig.acml können vorgenommen werden, wenn der Anwendungsserver ausgeführt wird. Der Anwendungsserver muss nicht neu gestartet werden, damit die Änderungen wirksam werden.

Hinweis

Ab APM Java Agent Version 1.12 wurde die Benennungskonvention für Servlet-, HttpClient- und OSB-Probes verbessert und vereinfacht. Daher ist die Regel replace_all_patterns zum Entfernen von Hex-ID und Zahlen nicht mehr standardmäßig in der Datei ProbeConfig.acml enthalten. Dies gilt für die Abschnitte SERVLET, HTTP_CLIENT und OSB.

Wenn Ihr spezifisches Szenario es noch erfordert, fügen Sie nach dem Upgrade des APM-Java-Agent Folgendes wieder in die Datei ein:
# Hex ID and numbers
-
      pattern: "([a-fA-F\._\:-]*[0-9]+){2,}[a-fA-F_\:-]*([/\.])?"
      replacement: "*$2"

Benutzerdefinierte Probe konfigurieren

Sie können eine benutzerdefinierte Probe konfigurieren, um zusätzliche Klassen zu überwachen und anwendungsspezifische Details abzurufen.

Die benutzerdefinierte Probe ist nützlich, wenn die in der Datei ProbeConfig.acml verfügbaren integrierten Probes die Monitoringanforderungen nicht erfüllen. Beispiel: Wenn Sie einen Hintergrundthread überwachen möchten, der mit den Standard-Probes nicht überwacht wird, können Sie eine benutzerdefinierte Probe konfigurieren.

So konfigurieren Sie eine benutzerdefinierte Probe:

  1. Konfigurieren Sie eine Datei DirectivesConfig.acml, um anzugeben, welche classes, methods oder annotations überwacht werden sollen. Weitere Informationen finden Sie unter DirectivesConfig.acml-Dateikonfiguration.
  2. Fügen Sie die Datei DirectivesConfig.acml zum Verzeichnis oracle-apm-agent/config hinzu.
    Es ist jetzt veraltet, die Datei DirectivesConfig.acml im Startskript des Anwendungsservers wie folgt anzugeben:
    -Dcom.oracle.apm.agent.customDirectivesFile=<Path_to_DirectivesConfig.acml_file>
    Entfernen Sie das obige Argument aus dem Startskript der Anwendung, wenn Sie die Datei DirectivesConfig.acml zuvor auf diese Weise angegeben haben.
  3. Starten Sie den Anwendungsserver neu, wenn eine neue DirectivesConfig.acml-Datei angegeben ist.

    Die Änderungen an der Datei DirectivesConfig.acml werden wirksam, nachdem Sie den Anwendungsserver neu gestartet haben.

    Der Neustart des Anwendungsservers ist erforderlich, wenn Sie eine neue DirectivesConfig.acml-Datei angeben oder die Datei löschen.

    Der Neustart des Anwendungsservers ist nicht erforderlich, wenn eine der folgenden Aktionen ausgeführt wird:
    • Bearbeiten Sie span_name.
    • Fügen Sie tags, logs oder Erweiterte Variablen in einer vorhandenen DirectivesConfig.acml-Datei hinzu, bearbeiten oder löschen Sie sie, die bereits gültig ist.
    Der Neustart des Anwendungsservers ist erforderlich, wenn Sie andere Parameter aus der folgenden Tabelle unter DirectivesConfig.acml-Parameter ändern.

DirectivesConfig.acml-Dateikonfiguration

Um die Datei DirectivesConfig.acml zu konfigurieren, prüfen Sie Folgendes:

DirectivesConfig.acml-Parameter

Nachfolgend finden Sie Informationen zu den Parametern, die Sie in der Datei DirectivesConfig.acml angeben können.

Mindestens einer der folgenden Parameter MUST wird in der Datei DirectivesConfig.acml angegeben:

  • class_name
  • class_name_regex
  • class_annotation
  • method_annotation
  • class_annotation_regex
  • method_annotation_regex
Parameter Beschreibung Beispiel
label

Ein eindeutiges Label für die Anweisung. Dies ist ein obligatorischer Parameter.

Test:
  ...
Test2:
  ...
Test3:
  ...
class_name

Der Name der zu überwachenden Klasse. Sie müssen den vollständigen Klassennamen einschließlich des Packages angeben.

Test:  
  class_name: "com.oracle.apm.samples.servlet.OutboundTestServlet"
class_name_regex

Ein Muster eines regulären Ausdrucks, mit dem alle übereinstimmenden Klassen überwacht werden.

Verwenden Sie für dieses Muster für das Package "/" anstelle von ".". Beispiel: Wenn Sie eine Klasse mit dem Namen a.b.c.d.ClassName überwachen möchten, muss das Muster des regulären Ausdrucks mit a/b/c/d/ClassName übereinstimmen.

Wenn sowohl class_name_regex als auch class_name angegeben sind, wird class_name ignoriert.

Test:
  # Monitor all classes under the com.oracle.apm.test package
  class_name_regex: "com/oracle/apm/test/.*"
method_name

Der Name der zu überwachenden Methode. Darin sind keine Methodenparameter enthalten.

Wenn method_name nicht angegeben ist, werden alle Methoden überwacht.

Test:
  class_name: "com.oracle.apm.samples.servlet.OutboundTestServlet"
  method_name "performHttpURLConnectionCall"
method_name_regex

Ein Muster eines regulären Ausdrucks, mit dem alle übereinstimmenden Methoden überwacht werden.

Wenn method_name_regex nicht angegeben ist, werden alle Methoden überwacht.

Wenn sowohl method_name_regex als auch method_name angegeben sind, wird method_name ignoriert.

Test:
  class_name: "com.oracle.apm.samples.servlet.OutboundTestServlet"
  # Monitor all methods that start with "perform"
  method_name_regex: "perform.*"
class_annotation

Der vollständige Klassenname der zu überwachenden Annotation. Jede class mit der angegebenen Annotation wird überwacht.

Test:
  class_annotation: "javax.jws.WebService"
method_annotation

Der vollständige Klassenname der zu überwachenden Annotation. Jede method mit der angegebenen Annotation wird überwacht.

Test:
  method_annotation: "javax.jws.WebMethod"
class_annotation_regex

Ein Muster eines regulären Ausdrucks, mit dem alle übereinstimmenden Klassenannotationen überwacht werden.

Verwenden Sie für dieses Muster für das Package "/" anstelle von ".". Außerdem muss der Wert mit "L" beginnen und mit ";" enden. Beispiel: Wenn Sie eine Annotation mit dem Namen a.b.c.d.Annotation überwachen möchten, muss das Muster des regulären Ausdrucks mit La/b/c/d/Annotation; übereinstimmen.

Wenn sowohl class_annotation_regex als auch class_annotation angegeben sind, wird class_annotation ignoriert.

Test:
  # Monitor all Path annotations in javax
  class_annotation_regex: "Ljavax/.*/Path;"
Test2:
  # Monitor all annotations that end with "Path"
  # The L in the beginning is not required since .* includes it
  class_annotation_regex: ".*/Path;"
Test3:
  # Monitor all annotations with the javax.jws package
  # The ; at the end is not required since .* includes it
  class_annotation_regex: "Ljavax/jws/.*"
method_annotation_regex

Ein Muster eines regulären Ausdrucks, mit dem alle übereinstimmenden Methodenannotationen überwacht werden.

Verwenden Sie für dieses Muster für das Package "/" anstelle von ".". Außerdem muss der Wert mit "L" beginnen und mit ";" enden. Beispiel: Wenn Sie eine Annotation mit dem Namen a.b.c.d.Annotation überwachen möchten, muss das Muster des regulären Ausdrucks mit La/b/c/d/Annotation; übereinstimmen.

Wenn sowohl method_annotation_regex als auch method_annotation angegeben sind, wird method_annotation ignoriert.

Test:
  # Monitor all Path annotations in javax
  method_annotation_regex: "Ljavax/.*/Path;"
Test2:
  # Monitor all annotations that end with "Path"
  # The L in the beginning is not required since .* includes it
  method_annotation_regex: ".*/Path;"
Test3:
  # Monitor all annotations with the javax.jws package
  # The ; at the end is not required since .* includes it
  method_annotation_regex: "Ljavax/jws/.*"
include_sub_classes

Geben Sie an, ob Unterklassen der Zielklasse überwacht werden sollen. Standardmäßig ist dieser Wert auf false gesetzt.

Test:
  class_name: "com.oracle.apm.samples.servlet.OutboundTestServlet"
  method_name "performHttpURLConnectionCall"
  include_sub_classes: true
span_name

Der Name des während des Monitorings erstellten Spans. Wenn span_name nicht angegeben ist, wird standardmäßig "${class_name}.${method_name}" verwendet.

Beachten Sie, dass Sie einen Namen für den Span angeben können, wie unter dem Label Test im entsprechenden Beispiel gezeigt. Dieser Name wird dann bei jedem Aufruf des überwachten Ziels verwendet.

Wenn Sie den Parameter span_name angeben, können Sie auch Variablen, ${variable_name} und Erweiterte Variablen verwenden, um zusätzliche Informationen zu den Parametern abzurufen, die Sie überwachen, und diese im Namen des Bereichs anzuzeigen. Im entsprechenden Beispiel gibt die Variable param# unter dem Label Test2 die entsprechenden Parameter der überwachten Methode an.

Test:
  ...
  # The same name will be used every time the target class/method is invoked
  span_name: "SpecialName"
Test2:
  ...
  # Use the toString result of the first parameter passed to the monitored method
  span_name: "${param1}"
tags

Die Tags (Namen und Werte), die im Span enthalten sein sollen.

Wie beim Parameter span_name können Sie mit Variablen zusätzliche Informationen zu den überwachten Parametern abrufen und anzeigen, wenn Sie Werte für tags angeben.

Beachten Sie, dass die von Ihnen angegebenen tags als Dimensionen auf der Trace-Explorer-Benutzeroberfläche angezeigt werden.

Für Tagwerte kann ein optionaler Typ angegeben werden. Mit der entsprechenden Syntax und dem entsprechenden Schlüsselwort (wie im Beispiel gezeigt) können Sie als Tagwert den Typ String, Boolean, Integer, Long, Float oder Double angeben. Der Standard-Tagwerttyp ist "Zeichenfolge". Wird verwendet, wenn kein Typ oder ein inkompatibler Typ angegeben ist. Wenn ein inkompatibler Typ für einen Tagwert angegeben wird, wird der Typ auf den Standardwert "Zeichenfolge" zurückgesetzt, und es wird eine Logmeldung zur Inkompatibilität angezeigt. Der Wert der Span-Dimension kann über Abfragen mit Aggregationen bestätigt werden, die numerische Werte (falls zutreffend) im Trace-Explorer verwenden.

Test:
  ...
  tags:
    importantInfo: "${param1}"
    consistentTag: "AlwaysTheSame"
    returnValue: "${return}"
    #The below tag will have value of default type String since no type was specified
    defaultTagType: "${param1}"
    #The below tag will have value of type Integer
    integerTag: "${param1} | integer"
    #The below tag will have value of type String, because the actual value type String, and the specified type Double are incompatible. Therefore it will default to String.
    booleanTag: "${param2} | double"
logs

Die Logs (Namen und Werte), die in den Span aufgenommen werden sollen.

Wie bei den Parametern span_name und tags können Sie auch Variablen verwenden, wenn Sie Werte für den Parameter logs angeben, um zusätzliche Informationen zu den überwachten Parametern abzurufen und anzuzeigen.

Beachten Sie, dass die angegebene logs in der Benutzeroberfläche des Trace-Explorers als Span-Logs angezeigt wird.

Test:
  ...
  logs:
    importantInfoLog: "${param1}"
    consistentLog: "AlwaysTheSame"
    returnValueLog: "${return}"
  ...

span_name, Tags und Logvariablen

Wenn Sie die Parameter span_name, tags und logs angeben, können Sie mit den folgenden Variablen zusätzliche Informationen abrufen:

  • class_name: Name der überwachten Klasse, einschließlich Package.
  • short_class_name: Name der überwachten Klasse ohne Package.
  • method_name: Name der überwachten Methode.
  • method_descriptor: Deskriptorformat der Signatur der überwachten Methode.
  • param#: Parameter der überwachten Methode, wobei param1 den ersten Parameter, param2 den zweiten Parameter usw. angibt.
  • this: Das überwachte Objekt. Wenn die überwachte method static ist, ist die Variable this nicht verfügbar.
  • return: Rückgabewert der überwachten Methode.
    Hinweis

    Die Variable return kann nur für den Parameter tags und nicht für span_name verwendet werden.

DirectivesConfig.acml - Beispiel

Beispiel für die Datei DirectivesConfig.acml:

Test:
  class_name: "com.oracle.apm.samples.servlet.OutboundTestServlet"
  method_name: "performHttpURLConnectionCall"
  include_sub_classes: true
  span_name: "${short_class_name}.${method_name}"
  tags:
    targetURL: "${param2}"
    port: "${param1}"

Basierend auf dem obigen Beispiel:

  • com.oracle.apm.samples.servlet.OutboundTestServlet.performHttpURLConnectionCall wird zusammen mit den Unterklassen überwacht.
  • Der im Trace-Explorer angezeigte Name des Spans lautet OutboundTestServlet.performHttpURLConnectionCall.
  • Die Tags targetURL und port werden dem Span hinzugefügt und verwenden die Werte des ersten und zweiten Parameters der Methode performHttpURLConnectionCall.

Die folgenden Screenshots zeigen ein Beispiel für die Seite der benutzerdefinierten Probe:

Beispiel für benutzerdefinierte Probe - Screenshot 1

Beispiel für benutzerdefinierte Probe - Screenshot 2

Erweiterte Variablen für benutzerdefiniertes Probing

Wenn Sie benutzerdefinierte Stichproben verwenden, können Sie erweiterte Befehlssyntax konfigurieren, um Variablen mithilfe von Methodenverkettung und Zeichenfolgenmanipulation über reguläre Ausdrücke dynamisch zu erstellen. Diese erweiterten Variablen können wie die anderen oben genannten Variablen in den Abschnitten span_name, tags und logs referenziert werden.

Allgemeiner Workflow zur Verwendung erweiterter Variablen
  1. Prüfen Sie, wie benutzerdefinierte Probe konfiguriert wird. Siehe Custom Probe konfigurieren.
  2. Prüfen Sie die Befehlskettensyntax. Siehe Command Chain-Syntax.
  3. Prüfen Sie die Beispiele. Siehe Beispiele für erweiterte Variablen.

Befehlskettensyntax

Eine Befehlskette besteht aus den folgenden drei Teilen:

Mit dem Pipe-Symbol "|" wird das Piping des Startobjekts an den ersten Kettenbefehl und das Piping-Ausgabeobjekt eines Kettenbefehls an den nächsten bezeichnet.

Ausführungszeit

Die Befehlsketten werden vor oder nach dem Aufrufen der überwachten Methode der benutzerdefinierten Probe ausgeführt. Dies wird durch die Ausführungszeit angegeben, die vor der SOI angezeigt wird.

<execution time> ::= [before || after]

Nicht alle Befehlsketten sind mit beiden Ausführungszeiten kompatibel: Wenn return als SOI oder als Parameter in einem Methodenbefehl verwendet wird, muss die Nachlaufzeit verwendet werden. Dies liegt daran, dass das Rückgabeobjekt erst nach dem Aufruf der überwachten Methode verfügbar ist. Wenn andere Variablen als SOIs oder Parameter in Methodenbefehlen verwendet werden, hängen Ausführungszeiten von den referenzierten Ketten ab.

Beispiel: Definieren Sie chain1 und chain2, wobei chain2 chain1 als SOI oder Parameter für einen Methodenbefehl verwendet. Beachten Sie, dass chain1 vor chain2 definiert werden muss, wenn beide Ketten dieselbe Ausführungszeit verwenden. Andernfalls muss chain1 vorher Ausführungszeit haben, und chain2 muss danach Ausführungszeit haben.

Weitere Informationen zur Verwendung von SOIs und den Methodenbefehlen finden Sie im folgenden Abschnitt Objekt-ID starten.

Startobjekt-ID

Eine Startobjekt-ID (SOI) kann Objekte sein, die folgenden Objekten zugeordnet sind:

  • Vordefinierte Schlüsselwörter: this, return und param#.

  • Ausgabe einer Kette, die durch ihren Schlüssel identifiziert wird.

Ausführungszeiten können mit SOI-Syntax gepaart werden.

SOI Beschreibung Mögliche Ausführungszeit Syntax Beispiel
ThisSOI Die Kette wird für das Objekt ausgeführt, das in der Datei DirectivesConfig.acml durch class_name angegeben ist. before oder after <this SOI> ::= [before || after] this thisSOIchain: before this | method (public getAddress ())
ParamSOI Die Kette wird für das Objekt ausgeführt, das in der Datei DirectivesConfig.acml durch param# angegeben ist.

Dies sind Parameter der überwachten Methode.

before or after <param_SOI> ::= [before || after] param# paramSOIchain: before param1 | method (public getAddress ())

param1 gibt den ersten Parameter an.

ReturnSOI Die Kette wird für das Objekt ausgeführt, das in der Datei DirectivesConfig.acml durch return angegeben ist.

Dies ist der Rückgabewert der überwachten Methode.

after <return_SOI> ::= [after] return returnSOIchain: after return | method (public getAddress ())
StaticSOI Die Kette wird mit keinem Objekt gestartet. before or after <static SOI> ::= [before || after] static staticSOIchain: before static | static method((com.test.beans.Employee)(public getLevel()))
VariableSOI Die Kette wird für das Objekt ausgeführt, das durch eine der obigen Variablen angegeben wird, die in der Datei DirectivesConfig.acml definiert sind. before or after <variable_SOI> ::= [before || after] variable-key var1: this | method (public setNewAddress (string "Variable Street", string "Redwood City", string "California", int 94065, string "US"))

var1UsedAsStartObject: after var1 | method (public getAddress ()) | field(private street)

Kettenbefehlsfolge

Eine Chain-Befehlsfolge besteht aus einem oder mehreren Chain-Befehlen.

Syntax: <chain_command_sequence> ::= <chain_command> || <chain_command> | <chain_command_sequence>

Kettenbefehlstypen

Syntax: <chain_command> ::= <method_command> || <field_command> || <regex_command>

Methodenbefehl

Mit einem Methodenbefehl wird eine Methode aufgerufen. Die Ausgabe eines Methodenbefehls ist das Rückgabeobjekt dieser spezifischen Methode.

Ein Methodenbefehl besteht aus der Methodensichtbarkeit, dem Methodennamen und der Parameterfolge. Dies entspricht der Methodensignatur.

Die Syntax sollte wie folgt aussehen:

<method_command> ::= method(<visibility> <java_identifier> (<parameter_sequence>))

<visibility> ::= private || public || protected || package

Mit dem Wert package wird eine Package-private (no-modifier)-Sichtbarkeitsmethode oder ein Feld angegeben.

<scalar_parameter_type> ::= int || double || float || String

<parameter> ::=<scalar_parameter_type> value || this || return || param<index> || variable-key

<parameter_sequence> ::= <parameter> || <parameter> , <parameter_sequence>

Methodenbefehlsbeispiele

  • Diese Kette zeigt this als Benutzerobjekt an. Diese Kette ruft die öffentliche getAddress-Methode in der Benutzerklasse auf. Die Ausgabe dieser Kette ist die Zeichenfolgendarstellung der Adresse dieses Benutzers.
    addresschain: this | method (public getAddress ())
  • Diese Kette ruft die Methode public setName für den Benutzer auf und setzt den Namen auf "John Smith". Da diese Set-Methode keinen Rückgabewert aufweist, ist die Ausgabe dieser Kette Null. Diese Kette zeigt, wie skalare Parameter in Methodenbefehlen verwendet werden.
    testSetupVar: this | method(public setName(String "John", String "Smith"))
  • Diese Kette verwendet param1 (den ersten Parameter der überwachten Methode) als Parameter für die Methode, die wir aufrufen.
    testParamAsParam: this | method(public incUserId(param1))
  • Diese Kette verwendet eine andere Variable, in diesem Fall testParamAsParam, als Parameter für die Methode.
    testVarAsParam: this | method(public incUserId(testParamAsParam))
  • Diese Kette ruft die Super-Methode explizit auf.
    invokeUsingSuper: this | method(private super.overloadPrivate(String "string3", int 2222))

Feldbefehl

Mit einem Feldbefehl werden Feldwerte geprüft. Die Ausgabe eines Feldbefehls ist das Objekt in diesem spezifischen Feld.

Ein Methodenbefehl besteht aus Feldsichtbarkeit und Feldname.

Syntax: <field_command> ::= field (<visibility> <java_identifier>)

Beispiele für Feldbefehle

Im folgenden Beispiel wird davon ausgegangen, dass this ein Benutzerobjekt ist. Hier greifen wir auf Felder mit unterschiedlicher Sichtbarkeit in der Benutzerklasse zu. Die Ausgabe jeder Kette ist der Wert des jeweiligen Feldes.
fieldPublic: this | field(public firstName)
fieldProtected: this | field (protected lastName) 
fieldPackagePrivate: this | field (package middleName)
fieldPrivate: this | field (private maidenName)

Static-Methodenbefehl

Mit einem statischen Methodenbefehl wird eine statische Methode aufgerufen. Die Ausgabe eines statischen Methodenbefehls ist das Rückgabeobjekt dieser spezifischen Methode.

Ein Methodenbefehl besteht aus einer Startklasse, einer Methodensichtbarkeit, einem Methodennamen und einer Parameterfolge. Dies imitiert die Methodensignatur.

Die Syntax sollte wie folgt aussehen:
<static_method_command> ::= static method((<starting_class>)(<visibility> <java_identifier> (<parameter_sequence>)))

Die Startklasse ist die Klasse, in der die statische Methode gefunden wird.

Beispiele für statische Methodenbefehle
  • Diese Kette beginnt ohne Objekt. Diese Kette ruft die öffentliche getlevel-Methode in der Klasse "Employee" auf. Die Ausgabe dieser Kette ist die Zeichenfolgendarstellung der Ebene dieses Mitarbeiters.
  • staticMethodPublic: static | static method((com.test.beans.Employee)(public getLevel()))
  • Die Verwendung anderer Visibilitäten und verschiedener Arten von Methodenparametern ist mit den Beispielen für den Methodenbefehl identisch.

Befehl für statisches Feld

Ein statischer Feldbefehl wird verwendet, um statische Feldwerte zu prüfen. Die Ausgabe eines statischen Feldbefehls ist das Objekt in diesem spezifischen Feld.

Ein Methodenbefehl besteht aus einer Startklasse, Feldsichtbarkeit und einem Feldnamen.

Syntax:

Die Syntax sollte wie folgt aussehen:
<static_field_command> ::= static field ((<starting_class>)(<visibility> <java_identifier>))

Beispiele für statische Feldbefehle:

Im folgenden Beispiel wird davon ausgegangen, dass this ein Benutzerobjekt ist. Hier greifen wir auf Felder verschiedener Sichtbarkeit in der Benutzerklasse zu. Die Ausgabe jeder Kette ist der Wert des jeweiligen Feldes.

staticFieldPublic: static field((com.test.beans.Employee)(public role))

Die Verwendung anderer Visibilitäten ist die gleiche wie in den Beispielen für Field Command.

Regex-Befehl

Mit einem regex-Befehl können Sie Zeichenfolgen suchen und/oder ersetzen, die sich aus der SOI ergeben, Rückgabewerte der Methodenbefehle oder der Feldwerte. Die Ausgabe eines regex-Befehls ist eine Zeichenfolge.

Ein regex-Befehl besteht aus der regex-Zeichenfolge. Optional kann er auch aus einer Ersatzzeichenfolge bestehen, zusammen mit der Angabe, ob das erste oder alle Vorkommen ersetzt werden sollen.

Syntax: <regex_command> ::=regex (string [,<replace-string> [, first || all]])

Beispiele für Regex-Befehle

  • Nachdem Sie die Adresse "100 Oracle Pkway, Redwood City, CA 94065" erhalten haben, ersetzen Sie den ersten "Pk" durch "This", in dem Sie "100 Oracle Thatway, Redwood City, CA 94065" erhalten haben
    replaceFirstChain : this | method (public getStreet()) | regex(Pk, This, first)
  • Nachdem Sie die Adresse "100 Oracle Pkway, Redwood City, CA 94065" erhalten haben, ersetzen Sie alle "0" durch "1", um "111 Oracle Pkway, Redwood City, CA 94165" zu erhalten.
    replaceAllChain: this | method (public getStreet()) | regex(0, 1, all)

Beispiele für erweiterte Variablen

Im Folgenden finden Sie ein Beispiel einer Befehlskette in der Datei DirectivesConfig.acml.

test:  class_name: "com.test.beans.User"
  method_name: "incAge"
  span_name: "${short_class_name}.${method_name}"
  tags:
    t: "${this}"
    params: "${param1}"
    r: "${return}"
    exampleVarTag: "${exampleVar}"
  variables:
    exampleVar:  before this | method (public getAddress ()) | field(private street) |  regex(Pk,This, all) | regex(This, That, first) 

Prüfung der Ausführung der Variablenkette exampleVar:

Die Kette exampleVar beginnt mit dem Benutzerobjekt, das in "class_name" angegeben ist. XX
  • Der erste Kettenbefehl ist ein Methodenbefehl, der ein Adressobjekt zurückgibt. Beispiel: "100 Oracle Pkway, Redwood City, CA 94065."

  • Der zweite Kettenbefehl ist ein Feldbefehl, der die Straße der Adresse aus dem vorherigen Feldbefehl abruft. Das wäre "Oracle Pkway".

  • Der dritte Kettenbefehl ist ein regex-Befehl, der alle Instanzen von "Pk" durch "This" ersetzt und "Oracle Thisway" zurückgibt.

  • Der letzte Chain-Befehl ist ein regex-Befehl, der die erste Instanz von "This" durch "That" ersetzt und "OracleThatway" zurückgibt.

Endgültiges Ergebnis: Wenn Sie Dimensionen dieses Spans anzeigen, wird ein Tag mit dem Namen exampleVarTag und dem Wert "OracleThatway" angezeigt. Beachten Sie, dass die Angabe von exampleVarTag: "${exampleVar}" im Tagabschnitt erforderlich war, um diese Span-Dimension anzuzeigen.

Verwenden Sie ACMLValidate, um die Dateisyntax zu prüfen

Wenn Sie mit Dateien vom Typ acml arbeiten, können Sie die Syntax der acml-Dateien mit dem Utility ACMLValidate prüfen.

ACMLValidate ist ein APM-Java-Agent-Utility, mit dem Sie die Syntax der folgenden acml-Dateien prüfen und prüfen können:
  • ProbeConfig.acml
  • DirectivesConfig.acml
  • CircuitBreaker.acml
Hinweis

Das Utility ACMLValidate validiert die Syntax, validiert die Werte jedoch nicht. Sie ist ab Version 1.16 des APM-Java-Agent verfügbar.

Voraussetzung:

JDK ist in PATH verfügbar, oder definieren Sie die Umgebungsvariable JAVA_HOME.

Speicherort:

Das Utility ACMLValidate befindet sich im Verzeichnis oracle-apm-agent/bin.

Führen Sie ACMLValidate aus:

Um ACMLValidate aufzurufen, verwenden Sie Folgendes:
  • Unter Windows: ACMLValidate.bat

  • Für Linux: ACMLValidate.sh

Syntax:
ACMLValidate.[bat|sh] <path to the acml file>
Beispiel1:
oracle-apm-agent/bin % sh ACMLvalidate.sh  ../config/1.16.0.560/ProbeConfig.acml
Die Ausgabe sieht in etwa wie folgt aus:
===============================================================================
Testing file: ../config/1.16.0.560/ProbeConfig.acml
ACML Validation Result: PASSED
===============================================================================
Beispiel2:
oracle-apm-agent/bin % sh ACMLvalidate.sh ../config/1.16.0.560/ProbeConfig.acml  
Die Ausgabe sieht in etwa wie folgt aus:
===========================================================================
Testing file: ../config/1.16.0.560/ProbeConfig.acml
ACML Validation Result: FAILED
Exception: Failed to parse line [5][  SERVLET: true]
Caused by: Tab detected in the following line.  Please replace '\t' with spaces: [  \tSERVLET: true]
===========================================================================