Inhaltsverzeichnis
Die Einarbeitung des Änderungseintrages wurde nicht vollständig umgesetzt. Zusätzlich wurden diverse Änderungen nur für PoPP umgesetzt und nicht generell übergreifend für die Telemetriedatenlieferung von TI2.0 Diensten.
Diese Thematik wird in der Änderung C_12761 angegangen, indem die fehlenden Produkttypen noch an die Afos angehangen werden, die das Thema der Client Zertifikate regeln und die bisher nur für PoPP gelten.
Afo wird storniert (wie in C_12662 bereits eingebracht)
A_27719 - Telemetriedatenlieferung - Nutzung eines gültigen Client-Zertifikats
Der Anbieter MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik ein gültiges TLS Client-Zertifikat nutzen.
Hinweis: Ein entsprechendes TLS Client-Zertifikat muss vor Inbetriebnahme bei der gematik beantragt werden. [<=]
Zuweisungen werden ergänzt
A_28890 - Verbindungsaufbau zum Telemetriedaten-Service
Der Anbieter MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik einen OAuth 2.0 Token Exchange (gem. RFC 8693) unterstützen.
Hinweis:
Die Basis für die Authentifizierung muss im Rahmen der Inbetriebnahme bei der gematik durchgeführt werden. [<=]
Anb_TI-D_ZT, Anb_DiPag_FD, Anb_VSDM_2_FD - Anbietererklärung
Zuweisungen werden ergänzt
A_28891 - Verbindungsaufbau zum Telemetriedaten-Service des Produkts
Das Produkt MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik einen OAuth 2.0 Token Exchange (gem. RFC 8693) unterstützen.
Hinweis:
Die Basis für die Authentifizierung muss im Rahmen der Inbetriebnahme bei der gematik durchgeführt werden. [<=]
Herst_TI-D_ZT, DiPag_FD, VSDM_2_FD – Herstellererklärung
Zuweisung VSDM2-FD wird entfernt, Afo wird nicht abgelöst (entgegen der Darstellung in C_12662)
A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls
Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß [A_26177*]) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]
Anb_VSDM_2_FD entfernen
Die Trace-Attribute entsprechen teilweise nicht den Open Telemetrie Vorgaben und sind, deshalb sowohl hinsichtlich der Tabelle, als auch bzgl. der Beispiele anzupassen. Darüber hinaus werden die Attribute und Beispiele sowohl aus Sicht des HTTP-Proxys des ZETA-Guard, als auch des Resource Servers, beschrieben.
Traces MÜSSEN dem OpenTelemetry Trace Data Model entsprechen und im Format des OpenTelemetry Trace Protobuf erzeugt werden. Die in dieser Spezifikation aufgeführten OpenTelemetry‑Attribute stellen eine gezielte Teilmenge dar, die für sicherheitsrelevante Analysen und Auswertungen vorgesehen ist. Die Spezifikation definiert bewusst nicht den vollständigen Umfang möglicher OpenTelemetry‑Attribute. Implementierungen DÜRFEN zusätzliche Attribute gemäß OpenTelemetry erfassen und übertragen; diese sind jedoch nicht Gegenstand der normativen Anforderungen dieser Spezifikation.
Ein gesendeter Trace enthält 1-n Spans, die grundlegende Einheit von einzelnen Operationen in einem verteilten System. Die Gesamtheit der Spans mit gleicher Trace ID ermöglicht eine Nachvollziehbarkeit der gesamten Kette eines Aufrufes.
Da es mit ZETA Guard und Resource Server unterschiedliche Komponenten gibt, die Traces erzeugen, werden die Codebeispiele und Parameter-Tabellen separat dargestellt. Bei der Übermittlung der Traces an die Telemetriedatenerfassung der gematik durch den ZETA Guard, spielt diese Trennung keine Rolle.
Hier in der Darstellung wird die OTLP/JSON Notation verwendet, die notwendigen und zugehörigen Attribute der OTLP/gRPC Notation (Proto) - welche für die technische Implementation der Anwendung relevant sind - sind der jeweils aktuell gültigen und veröffentlichten Beschreibung des OpenTelemetry Projektes zu entnehmen.
Hier ein Beispiel eines Traces Spans des HTTP Proxys:, der aus zwei einzelnen Operationen zusammengesetzt wird.
{
"resourceSpans": [
{
"resource": {
"attributes": [
{
"key": "service.name",
"value": {"stringValue": "ZETA Guard PEP HTTP proxy"}
}
]
},
"scopeSpans": [
{
"scope":{
"name": "proxy-tracing",
"version": "1.0.0"
},
"spans": [
{
"traceId": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"spanId": "1111111111111111",
"name": "HTTP GET /vsdservice/v1/vsdmbundle",
"kind": 2,
"startTimeUnixNano": "1714311000000000000",
"endTimeUnixNano": "1714311000200000000",
"attributes": [
{
"key": "http.method",
"value": {"stringValue": "GET"}
},{
"key": "http.route",
"value": {"stringValue": "/vsdservice/v1/vsdmbundle"}
},{
"key": "http.request.header.x-forwarded-for",
"value": {"stringValue": "203.0.113.10"}
},{
"key": "server.address",
"value": {"stringValue": "vsdm2.aok.net"}
},{
"key": "product_id",
"value": {"stringValue": "CLIENTID123456"}
},{
"key": "product_version",
"value": {"stringValue": "2.1.3-10"}
},{
"key": "profession_oid",
"value": {"stringValue": "1.2.276.0.76.4.30"}
}
],
"status":{
"code": 1
}
}
]
}
]
}
]
}
Die folgende Tabelle gibt Aufschluss über die möglichen Trace-Parameter des ZETA HTTP Proxy Spans. Die tabellarische Auflistung berücksichtigt nicht explizit die Hierarchie Ebene, diese kann aus dem Schema Beispiel entnommen werden.
Tabelle 1 Tab_gemSpec_Perf_Trace_HTTPSpanParameter_Telemetriedatenlieferung
| Daten | Open Telemetry Attribute (OTLP/JSON) | Pflichtfeld | Begründung und Zweck |
|---|---|---|---|
| Service Name | service.name
|
ja | Identifikationsmerkmal, fester Wert "ZETA Guard PEP HTTP proxy" |
| Startzeit | startTimeUnixNano | ja | Startzeitpunkt der Operation |
| Endzeit | endTimeUnixNano | ja | Endzeitpunkt der Operation |
| HTTP Methode | http.method | ja | Erkennung von unautorisierten Aktionen oder abnormalen Anfragen. Ein unerwarteter HTTP-Methoden-Typ auf einer bestimmten Route kann auf einen Angriffsversuch hindeuten. |
| HTTP Route | http.route | ja | Überwachung von Zugriffen auf spezifische Ressourcen und Erkennung von unautorisierten Zugriffen oder Versuchen, nicht existierende Routen zu erreichen (z.B. für Brute-Force-Angriffe oder Enumeration). |
| HTTP FQDN | server.address | ja | Identifikation des Zielservers bei Multi-Host-Umgebungen und Erkennung von Anfragen an nicht autorisierte oder verdächtige Domänen. |
| HTTP Status | http.response.status_code | ja | Erkennung von Fehlern, Ausfällen oder potenziellen Angriffsversuchen (z.B. viele 401/403-Fehler bei Brute-Force-Angriffen, viele 5xx-Fehler bei Denial-of-Service-Angriffen). |
| Product Id | product_id
|
ja | Product ID aus dem Token Self-Assessment des aufrufenden Clientsystems |
| Product Version | product_version
|
ja | Product Version aus dem Token Self-Assessment des aufrufenden Clientsystems |
| Profession OID | profession_oid
|
ja - sofern möglich | Profession OID aus dem SM-B Zertifikat des aufrufenden Clientsystems. Das Attribut ist nur für die Usecases zu übermitteln, in denen ein SM-B-Zertifikat Anwendung findet. |
Ergänzend zum ZETA Guard Proxy Span, hier das Beispiel eines Trace Span eines Resource Servers:
{
"resourceSpans": [
{
"resource": {
"attributes": [
{
"key": "service.name",
"value": {"stringValue": "vsdm2-service"}
}
]
},
"scopeSpans": [
{
"scope": {
"name": "rs-tracing",
"version": "1.0.0"
},
"spans": [
{
"traceId": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"spanId": "2222222222222222",
"parentSpanId": "1111111111111111",
"name": "HTTP GET backend-service",
"kind": 3,
"startTimeUnixNano": "1714311000205000000",
"endTimeUnixNano": "1714311000900000000",
"attributes": [
{
"key": "rs.statuscode",
"value": {"stringValue": "200"}
},{
"key": "rs.duration",
"value": {"intValue": 1234535345}
},{
"key": "pdt.ikn",
"value": {"intValue": 100000000}
},{
"key": "pdt.eTag",
"value": {"boolValue": false}
},{
"key": "pdt.eTagValue",
"value": {"boolValue": false}
}
],
"status": {
"code": 1
}
}
]
}
]
}
]
}
Die folgende Tabelle gibt Aufschluss über die möglichen Trace-Parameter. Beschrieben werden die allgemein gültigen Parameter sowie die für alle Ressource Server gültigen, beginnend mit dem Suffix "rs". Im Beispiel sind zusätzlich Key / Value Paare mit dem Präfix "pdt_", diese sind produkttypspezifisch und werden in entsprechenden Unterkapiteln (siehe Kapitel 3) beschrieben. Die tabellarische Auflistung berücksichtigt nicht explizit die Hierarchie Ebene, diese kann aus dem Schema Beispiel entnommen werden.
Tabelle 2 Tab_gemSpec_Perf_Trace_RSSpanParameter_Telemetriedatenlieferung
| Daten | Open Telemetry Attribute (OTLP/JSON) | Pflichtfeld | Begründung und Zweck |
|---|---|---|---|
| Service Name | service.name
|
ja | Identifikationsmerkmal, fester Wert zur Erkennung des Resource Servers |
| Trace-Id | traceId | ja | Eindeutige ID eines Traces und Kennzeichnung zueinander gehörender Operationen (wird vom OTEL Framework gesetzt) |
| Parent Span-Id | parentSpanId | ja | Eindeutige ID zur Identifizierung von Hierarchien innerhalb der Operationen eines Traces (wird vom OTEL Framework gesetzt) |
| Startzeit | startTimeUnixNano | ja | Startzeitpunkt der Operation
Entspricht "timestamp" der Betriebsdatenlieferung v2 |
| Endzeit | endTimeUnixNano | ja | Endzeitpunkt der Operation |
| Resource Server Statuscode | rs.statuscode
|
ja | Ein max. 5-stelliger Statuscode des Ressource Servers gemäß [A_27722-*]. Produkttypspezifische fachliche Fehlercodes sind hier vorrangig vor "Standard-HTTP-Statuscodes" zu verwenden.
Entspricht "status" der Betriebsdatenlieferung v2 |
| Resource Server Duration | rs.duration
|
ja | Dies ist eine vom Ressource Server berechnete Zeitdauer (in Millisekunden), wie lange die Verarbeitung der Operation intern benötigte.
Entspricht "duration_in_ms" der Betriebsdatenlieferung v2 |
| Resource Server Instanz | rs.instance
|
nein | Dies ist eine zusätzliche fachliche Instanz des Resource Servers. Wenn vorhanden vom Ressource Server befüllt. Das Feld ist optional. |
| Produkt spezifische Attribute | pdt.*
|
Produkttyp spezifische Anforderungen sind zu beachten | Im Beispiel sind zusätzlich Key / Value Paare mit dem Präfix "pdt_", diese sind produkttypspezifisch und werden in entsprechenden Unterkapiteln (siehe Kapitel 3) beschrieben.
Enthält die in der Betriebsdatenlieferung v2 beschriebenen Inhalte von "message". |
{
"trace_id": "abcd1234efgh5678ijkl9012mnop3456",
"spans": [
{
"span_id": "1111222233334444",
"service.name": "HTTP GET /api/user",
"start_time_unix_nano": 1678886400000000000,
"end_time_unix_nano": 1678886410000000000,
"attributes": [
{"http_fqdn": "vsdm2.aok.net"},
{"http_route": "/ressource/path/1"},
{"http.request.method": "GET"},
{"http.response.status_code": 200} ,
{"product_id": "CLIENTID1234567890AB"},
{"product_version": "2.1.3-10"},
{"profOID": "1.2.276.0.76.4.30"}
],
"parent_id": null // Root-Span hat keinen Parent
},
{
"span_id": "5555666677778888",
"service.name": "rs-vsdm_2",
"start_time_unix_nano": 1678886430000000000,
"end_time_unix_nano": 1678886440000000000,
"attributes": [
{"http_fqdn": "vsdm2.aok.net"},
{"http_route": "/ressource/path/1"},
{"http.request.method": "GET"},
{"http.response.status_code": 200},
{"rs_statuscode": 200},
{"key": "pdt_size", "value": { "intValue": 456}},
{"key": "pdt_ikn", "value": { "intValue": 128}},
{"key": "pdt_eTag", "value": { "boolValue": false}},
{"key": "pdt_eTagValue", "value": { "boolValue": false}}
],
"parent_id": "1111222233334444" // Parent-Span-ID des Root-Spans
}
]
}
Fehlt in der Kette der Operationen ein Span eines Ressource Servers kann daraus abgeleitet werden, dass der Ressource Server ausgefallen ist.
Die folgende Tabelle gibt Aufschluss über die möglichen Trace-Parameter. Beschrieben werden die allgemein gültigen Parameter sowie die für alle Ressource Server gültigen, beginnend mit dem Suffix "rs". Im Beispiel sind zusätzlich Key / Value Paare mit dem Präfix "pdt_", diese sind produkttypspezifisch und werden in entsprechenden Unterkapiteln (siehe Kapitel 3) beschrieben.
Tabelle 3: Tab_gemSpec_Perf_Trace_Parameter_Telemetriedatenlieferung
| Attributname | zugehörige Operation | Beschreibung |
|---|---|---|
| trace_id | alle | Eindeutige ID eines Traces und Kennzeichnung zueinander gehörender Operationen. Das Feld darf nicht leer sein. |
| span_id | alle | Eindeutige ID einer einzelnen Operation innerhalb eines Traces. Das Feld darf nicht leer sein. |
| parent_id | alle | Eindeutige ID zur Identifizierung von Hierarchien innerhalb der Operationen eines Traces. |
| service.name | alle | Name der Operation bzw. Servicename. Das Feld darf nicht leer sein. |
| start_time_unix_nano | alle | Startzeitpunkt der Operation. Das Feld darf nicht leer sein. |
| end_time_unix_nano | alle | Endzeitpunkt der Operation. Das Feld darf nicht leer sein. |
| attributes:http_fqdn | alle | Vollständiger FQDN der ausgeführten Operation. Das Feld darf nicht leer sein. |
| attributes:http_route | alle | HTTP Route der ausgeführten Operation. Das Feld darf nicht leer sein. |
| attributes:http.request.method | alle | HTTP Methode der ausgeführten Operation. Das Feld darf nicht leer sein. |
| attributes:http.response.status_code | alle | 3-stelliger HTTP Statuscode gemäß [RFC9110]. Das Feld darf nicht leer sein. |
| attributes:product_id | alle | Product ID aus dem Token Self-Assessment des aufrufenden Clientsystem |
| attributes:product_version | alle | Product Version aus dem Token Self-Assessment des aufrufenden Clientsystems |
| attributes:profOID | alle | profession OID aus dem SM-B Zertifikat des aufrufenden Clientsystems. Das Attribut ist nur für die Usecases zu übermitteln, in denen ein SM-B-Zertifikat Anwendung findet. |
| attributes:rs_duration | Ressource Server des TI 2.0 Dienst | Dies ist eine vom Ressource Server berechnete Zeitdauer (in Millisekunden), wie lange die Verarbeitung der Operation intern benötigte. Das Feld ist optional. |
| attributes:rs_instance | Ressource Server des TI 2.0 Dienst | Dies ist eine zusätzliche fachliche Instanz des Resource Servers. Wenn vorhanden vom Ressource Server befüllt. Das Feld ist optional. |
| attributes:rs_statuscode | Ressource Server des TI 2.0 Dienst | Ein max. 5-stelliger Statuscode des Ressource Servers gemäß [A_27722-*]. Produkttypspezifische fachliche Fehlercodes werden hier ebenfalls gemappt. Das Feld darf nicht leer sein. |
...
Zusätzlich zur Nachvollziehbarkeit von verteilten Transaktionen in einer Anwendung mittels Traces kann OpenTelemetry Logs erfassen. Die Telemetriedatenlieferung stellt einen Custom Collector für die Selbstauskunft zur Verfügung. Der ZETA Guard greift diesen Collector auf und lässt ihn durch den Ressource Server befüllen. Die Selbstauskunft wird an den Telemetriedaten-Service über einen OTLP-Exporter als OTEL Log Signal gesendet. Der ZETA Guard stellt einen OTEL Collector für Empfang, Anreicherung und den Weiterversandt der Selbstauskunft zur Verfügung.
Logdaten MÜSSEN dem OpenTelemetry Log Data Model entsprechen und im Format des OpenTelemetry Log Protobuf erzeugt und übertragen werden. Die in dieser Spezifikation beschriebenen OpenTelemetry‑Attribute stellen eine gezielte Teilmenge dar, die für sicherheitsrelevante Analysen und Auswertungen im Kontext der Selbstauskunft vorgesehen ist.
Diese Spezifikation erhebt keinen Anspruch auf Vollständigkeit hinsichtlich aller durch OpenTelemetry definierten Log‑Attribute. Implementierungen DÜRFEN zusätzliche Attribute gemäß OpenTelemetry erfassen und übertragen; diese sind jedoch nicht Gegenstand der normativen Anforderungen dieser Spezifikation, sofern sie die Auswertung der hier definierten Attribute nicht beeinträchtigen.
Hier ein Beispiel eines OTEL Log records.
{
"resourceLogs": [
{
"resource": {
"attributes": [
{"key": "product_nameproduct.name", "value": {"stringValue": "VSDM2_HerstellerX" }},
{"key": "product.code_name", "value": {"stringValue": "VSDM2X" }},
{"key": "producttyp_nameproduct.typ_name", "value":{"stringValue": "PDT79" }},
{"key": "lpi.ci_id", "value": {"stringValue": "CI-9876543" }},
{"key": "lpi.instance", "value": {"stringValue": "a" }},
{"key": "pod_name", "value": {"stringValue": "VSDM2.pod" }},
{"key": "product.vendor_id", "value": {"stringValue": "HERST" }},
{"key": "product.vendor_name", "value": {"stringValue": "Hersteller ABC" }}
]
},
"scopeLogs": [
{
"scope": {
"name": "com.example.MyLogger",
"version": "1.0.0"
},
"logRecords": [
{
"timeUnixNano": 1678886400000000000,
"body": { "stringValue": "Selbstauskunft" },
"severityText": "product_info",
"severityNumber": 9,
"attributes": [
{ "key": "product_versionproduct.version
", "value": { "stringValue": "1.2.0-0" }},
{ "key": "producttype_versionproduct.type_version
", "value": { "stringValue": "1.0.3" }},
{ "key": "configuration_versionconfiguration.version
", "value": {"stringValue": "1.3.4-2" }}
]
}
]
}
]
}
]
}
Die zum OpenTelemetry Log "product_info" gehörenden Attribute werden in der folgenden Tabelle beschrieben. Hier in der Darstellung wird die OTLP/JSON Notation verwendet, die notwendigen und zugehörigen Attribute der OTLP/gRPC Notation (Proto) - welche für die technische Implementation der Anwendung relevant sind - sind der jeweils aktuell gültigen und veröffentlichten Beschreibung des OpenTelemetry Projektes zu entnehmen.
Tabelle 4: Tab_gemSpec_Perf_Telemetriedaten_product_info
| Daten | OpenTelemetry Attribute (OTLP/JSON) | Pflichtfeld | Begründung und Zweck |
|---|---|---|---|
| Fester Wert zur Definition der Selbstauskunft | body | ja | "Selbstauskunft" |
| Fester Wert zur Definition der Selbstauskunft | severityText | ja | "product_info" |
| Fester Wert zur Definition der Selbstauskunft | severityNumber | ja | 9 |
| Produktname | product.name | Ja | Produktname, vom Hersteller vergeben
Entspricht "ProductName" der Selbstauskunft v1 |
| Produktkurzname | product.code_name | Ja | Produktkurzname, vom Hersteller vergeben
Entspricht "ProductCodt" der Selbstauskunft v1 |
| Produkttyp | product.type_name | Ja | Produkttyp mit numerischen Code, nach Vorgaben der gematik
Entspricht "ProductType" der Selbstauskunft v1 |
| CI-Identifikator | lpi.ci_id | Ja | Identifikation des Konfiguration-Elementes "logische Produktinstanz", beginnend mit "CI"
Entspricht "CI-ID" der Selbstauskunft v1 |
| CI-Instanz | lpi.instance | Nein | Identifikation der logischen Produktinstanz, sofern redundante Instanzen vorhanden sind |
| Pod Name | pod.name | Nein | Identifikation des laufenden Pods |
| Hersteller ID | product.vendor_id | Ja | Hersteller ID
Entspricht "ProductVendorID" der Selbstauskunft v1 |
| Herstellername | product.vendor_name | Ja | ausführlicher Herstellername
Entspricht "ProductVendorName" der Selbstauskunft v1 |
| Produktversion | product.version | Ja | Aktuelle Produktversion, vom Hersteller vergeben
Entspricht "ProductVersion" der Selbstauskunft v1 |
| Produkttyp Version | product.type_version | Ja | Aktuelle Produkttypversion, nach Vorgaben der gematik
Entspricht "ProductTypeVersion" der Selbstauskunft v1 |
| Konfigurationsversion | configuration.version | Ja | Aktuelle Konfigurationsversion, vom Hersteller vergeben |
| Parameter | Beschreibung |
|---|---|
| resource:attributes:product_name | Name des Produkts (durch Hersteller) |
| resource:attributes:producttyp_name | Name des Produkttyp (PDT-Nummer der gematik) |
| resource:attributes:pod_name | Name des Pods/der Instanz (durch Hersteller) |
| scopeLogs:logRecords:timeUnixNano | Zeitpunkt der letzten Änderung |
| scopeLogs:logRecords:body | { "stringValue": "Selbstauskunft" } |
| scopeLogs:logRecords:severityText | "product_info" |
| scopeLogs:logRecords:severityNumber | 9 |
| scopeLogs:logRecords:attributes:product_version | Aktuelle Produktversion (durch Hersteller) |
| scopeLogs:logRecords:attributes:producttype_version | Aktuelle Produkttypversion (PTV des Steckbriefes) |
| scopeLogs:logRecords:attributes:configuration_version | Aktuelle Konfigurationsversion (durch Hersteller) |
In A_27723 muss die Referenz auf die Traceparametertabellen geändert werden. Der Fokus der Afo wird geändert und zielt nur noch auf die Lieferung zwischen RS und ZETA Guard.
...
A_27723-03 - Performance - Telemetriedatenlieferung - Lieferung RS
Der Produkttyp MUSS für jede ausgeführte Operation die Betriebsdaten (Traces) mit Traceparametern gemäß der Tabelle "Tab_gemSpec_Perf_Trace_RSSpanParameter_Telemetriedatenlieferung" in einer Telemetriedatenlieferung an den Telemetriedaten-Service senden. Das Senden der Telemetriedaten SOLL asynchron erfolgen, um die Performance der Operation nicht negativ zu beeinflussen.
Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik. [<=]
neue Afo mit Referenz auf die Traceparameter für die Lieferung zwischen ZETA Guard und Telemetriedatencloud.
A_29020 - Performance - Telemetriedatenlieferung - Lieferung ZETA Guard HTTP Proxy
Der Produkttyp MUSS für jede ausgeführte Operation die Betriebsdaten (Traces) mit Traceparametern gemäß der Tabelle "Tab_gemSpec_Perf_Trace_HTTPSpanParameter_Telemetriedatenlieferung" in einer Telemetriedatenlieferung an den Telemetriedaten-Service senden. Das Senden der Telemetriedaten SOLL asynchron erfolgen, um die Performance der Operation nicht negativ zu beeinflussen.
[<=]
Zuweisen an ZT_Cluster - Test Produkt / FA
bei Afo A_28782 wird die Zuweisung des ZT_Clusters geändert:
alt ZT_Cluster - funkt. Eignung: Test Produkt/FA
neu ZT_Cluster - funkt. Eignung: Herstellererklärung
...
A_27494-01 wird angepasst und auf die neue Tabelle aus gemSpec_Perf referenziert:
A_27494-02 - Telemetriedaten-Service, Custom Collector für Selbstauskunft
Der Telemetriedaten-Service MUSS einen OTEL Collector für die Selbstauskunft des Resource Servers bereitstellen. Die Selbstauskunft des Resource Servers erfolgt für jede eigenständige Instanz als OTLP Log Record.
Der Telemetriedaten-Service MUSS einen Custom Collector (oder einen Collector mit einem Custom Processor) für die Selbstauskunft des Resource Servers implementieren. Die Selbstauskunft des Resource Servers erfolgt für jede eigenständige Instanz als OTLP Log Record.
Hinweis: Der OTLP Log Record für die Selbstauskunft ist wie folgt in gemSpec_Perf (Tab_gemSpec_Perf_Telemetriedaten_product_info) definiert:
Body: "Selbstauskunft".
Attributes:
product_name – Name des Produktsproduct_version – Aktuelle Produktversionproducttype_version – Version des Produkt-Typsconfiguration_version – Konfigurationsversionpod_name – Name des Pods/der Instanz des Resource Serverstimestamp – Der Zeitpunkt der Erstellung des Log Records (wird automatisch gesetzt).