Métricas
Métricas de Pago
Los métricas de pago se producen cuando un pago ha finalizado. Son un contador de pagos finalizados, la duración del pago de extremo a extremo, y si está configurado, la duración del camino crítico de los pagos y su tiempo de espera.
Cada métrica también está etiquetada, consulte el [Labels] sección para más información.
Métricas Disponibles
Pagos Finalizados
La métrica ipf_businessmetrics_payments_finished_total representa un conteo de pagos finalizados.
Un pago se determina que está finalizado cuando su global state es terminal; esta información se proporciona en el events recibido de IPF Processing Data.
Duración del Pago de Extremo a Extremo
La métrica ipf_businessmetrics_payments_duration_seconds representa la duración de los pagos finalizados, como tres métricas separadas.
| Métrica | Descripción |
|---|---|
|
El número total de duraciones producidas. Habrá una por cada pago finalizado. Si cinco pagos finalizan, este contador será cinco. |
|
La mayor duración de pago (en segundos). |
|
La suma de todas las duraciones de pago (en segundos). |
Estas métricas le permiten determinar la duración media de los pagos, por ejemplo.
Duración de la Ruta Crítica
La métrica ipf_businessmetrics_payments_criticalpath_duration_seconds representa el tiempo que los pagos se gastaron en la ruta crítica configurada.
El camino crítico se define por un inicio y un final.state, y puede ser diferente entre los diferentes tipos de pago. Esta métrica solo se produce si el pago finalizó en ambos estados de inicio y fin.
El procesador de métricas primero examinará los datos entrantes events y intente calcular la duración de la ruta crítica a partir de esos events que están etiquetados CRITICAL_PATH_START, y CRITICAL_PATH_END. Si no se puede determinar la duración, y existe una configuración heredada (véase más abajo), se utilizará la configuración para calcular la duración del camino crítico. Si ninguno de los enfoques tiene éxito, la métrica no se publicará.
El CRITICAL_PATH_START, y CRITICAL_PATH_END las etiquetas pueden aparecer en events_a través de_ flujos para un unit of work. Debe haber un final que coincida con cada inicio.
Es posible que un unit of work para iniciar y finalizar muchos caminos críticos. En este caso, la duración del camino crítico es la suma. Si ocurren caminos críticos más pequeños dentro de un camino crítico más grande, se utiliza el camino crítico más grande.
La duración de la ruta crítica se define como tres métricas separadas.
| Métrica | Descripción |
|---|---|
|
El número total de duraciones producidas. Habrá una por cada pago finalizado que haya pasado por un camino crítico. Si cinco pagos finalizan y tres pasaron por un camino crítico, este contador será tres. |
|
La mayor duración del camino crítico (en segundos). |
|
La suma de todas las duraciones del camino crítico (en segundos). |
Estas métricas le permiten determinar la duración media del camino crítico, por ejemplo.
Configuración de la Ruta Crítica - Obsoleto
| Esta configuración está obsoleta y existe únicamente por compatibilidad hacia atrás. No será compatible en una futura versión. |
| Esta configuración no es necesaria si payment flows producir events con etiquetas que indican el inicio y el final de la ruta crítica. |
La configuración de la Ruta Crítica define cualquier número de payment-type-mappings que especifican cómo calcular la Duración de la Ruta Crítica para un tipo de pago dado.
ipf.business-metrics-processor.payment-metrics.payment-duration {
critical-path {
critical-path-states-by-payment-type = [
{
paymentType = "Debtor CT"
start-state = "Validating"
end-state = "Instructing"
}
]
}
}La configuración anterior solo calculará la duración del camino crítico de Debtor CT tipos de pago. La Duración se calcula tomando la diferencia entre la marca de tiempo de la Process Flow Event con status.globalStatus=Validating y la marca de tiempo del Process Flow Event con status.globalStatus=Instructing
Duración de la Espera
Las métricas de duración de espera indican cuánto tiempo los pagos pasan en estados de espera predefinidos.
La métrica ipf_businessmetrics_payments_waiting_duration_seconds representa el tiempo que los pagos pasan en estados de espera predefinidos. Este es típicamente el tiempo que el IPF payment flows gasto de espera en sistemas externos, como los proporcionados por el banco cliente, por ejemplo, cuando el payment flow realiza una llamada al sistema de un banco para llevar a cabo parte del procesamiento de pagos.
Los estados de espera se definen en estados o events in payment flows. Cuando el Procesador de Métricas recibe events(que incluye un nuevo resultado state) que contiene la etiqueta WAITING_DURATION, calcula el tiempo empleado en el resultado state y sumas con todos los demás estados de espera. Si un pago comprende muchos flujos, la suma de todos los estados de espera a través de los flujos es la duración total de espera.
Si el entrante events no están etiquetados, y existe una configuración heredada (véase a continuación), la configuración se utilizará para calcular la duración total de espera. Si ninguno de los enfoques tiene éxito, la métrica no se publica.
|
Ejemplo
Un pago se procesa mediante un flujo único que puede estar en los estados [A, B, C, D, E] donde B se considera un estado de espera.state. El tiempo que el payment flow las transiciones de A a B (ingresando a B) es el tiempo de inicio, y el tiempo que el payment flow Las transiciones de B a C (saliendo de B) son el tiempo de finalización. La diferencia entre el tiempo de inicio y el tiempo de finalización es la duración de la espera. Un pago puede ser procesado por muchos flujos, cada uno con muchos posibles estados de espera. La duración de espera de los pagos es la suma del tiempo que ha pasado en todos los estados de espera. |
Esta métrica solo se produce si el pago final realmente pasó tiempo esperando, y al igual que las otras métricas de duración, se define como tres métricas separadas.
| Métrica | Descripción |
|---|---|
|
El número total de duraciones producidas. Habrá una por cada pago finalizado que haya pasado un tiempo no nulo esperando. Si cinco pagos finalizan y tres pasaron tiempo esperando, este contador será tres. |
|
La mayor duración de espera (en segundos). |
|
La suma de todas las duraciones de espera (en segundos). |
Estas métricas le permiten determinar la duración media de espera, por ejemplo. "ipf_businessmetrics_payments_waiting_duration_seconds_sum" / "ipf_businessmetrics_payments_waiting_duration_seconds_count"
Configuración de la Duración de Espera - Obsoleto
| Esta configuración está obsoleta y existe únicamente por compatibilidad hacia atrás. No será compatible en una futura versión. |
| Esta configuración no es necesaria si payment flows producir events con etiquetas que indican los estados de espera. |
La configuración de la Duración de Espera define una lista de estados por flujo que se consideran como estados de espera. Estos estados coinciden con el Estado Resultante y el Estado de Origen de dos Process Flow Events que son ingeridos para un Flujo dado.
ipf.business-metrics-processor.payment-metrics.payment-duration {
waiting {
waiting-states-by-flow = [
{
flow-name = "PaymentExecutionFlowV1"
states = [ "Checking Bank System A", "Checking Bank System B" ]
}
]
}
}Dada la configuración anterior, los estados de espera para PaymentExecutionFlowV1 are Checking Bank System A y Checking Bank System B. Esto significa que para un pago de este flujo, la duración de espera es la suma de las siguientes dos Duraciones:
-
La duración entre la marca de tiempo de la Process Flow Event con
status.resultingStatus=Checking Bank System Ay la marca de tiempo del Process Flow Event constatus.originatingStatus=Checking Bank System A -
La duración entre la marca de tiempo de la Process Flow Event con
status.resultingStatus=Checking Bank System By la marca de tiempo del Process Flow Event constatus.originatingStatus=Checking Bank System B=== Etiquetas
Las etiquetas se aplican a todas las métricas de pago producidas, y pueden ser utilizadas para profundizar en esas métricas, por ejemplo, el conteo de todos los pagos finalizados que son Completed vs Cancelled, o un recuento de todos los pagos finalizados que se realizaron a través de la CSM RT1.
|
Valores de Etiqueta Predeterminados
En la mayoría de los casos, un valor de etiqueta predeterminado de Esto puede ocurrir cuando la fuente para el valor de la etiqueta nunca se recibe, por ejemplo, no hay |
Etiquetas con clave ipf.business-metrics-processor.payment-metrics.labels - Obsoleto
| La siguiente configuración está obsoleta y existe únicamente por compatibilidad hacia atrás. No será compatible en una futura versión. Consulte la configuración de etiquetas versionadas:Versionado PDS Etiquetas |
Las métricas de pago se etiquetarán con lo siguiente..
| Etiqueta | Descripción |
|---|---|
csm |
El CSM del pago Mapeado de un |
moneda |
La moneda del pago Mapeado cuando la moneda mappings están configurados, y la fuente configurada PDS el objeto es producido por un pago. |
dirección |
La dirección del pago. Mapeado cuando dirección mappings están configurados, y el pago produce un |
htm |
A flag que indica si un pago se realizó Human Task Manager Siempre presente con un valor predeterminado de "No", y solo "Sí" cuando los pagos producen un event que se considera un HTM event. |
tipoDePago |
El tipo de pago Mapeado de un |
state |
El global final state del pago. |
localInstrument |
El instrumento local que facilita la transferencia de fondos. Mapeado cuando el instrumento local mappings están configurados, y la fuente configurada PDS el objeto es producido por un pago. |
clientChannel |
El canal de iniciación de pago del cliente utilizado para un pago. Mapeado cuando el canal del cliente mappings están configurados, y la fuente configurada PDS el objeto es producido por un pago. |
errorCode |
El código de error más reciente para un dado unit of work. Siempre presente con un valor predeterminado de "Ninguno" cuando no hay códigos de error para el unit of work. |
identityComparison |
El resultado de comparación de identidad más reciente realizado para el unit of work Mapeado cuando se compara la identidad mappings están configurados, y la fuente configurada PDS objeto que contiene un valor booleano verdadero/falso, el valor de coincidencia/no coincidencia es producido por un pago. Siempre presente con el valor predeterminado de "NotExecuted" si no se realizaron comparaciones. |
processingEntity |
La entidad de procesamiento para el unit of work Siempre presente con el valor predeterminado de "Ninguno" si no hay ninguna entidad de procesamiento conocida. |
claves de contexto de soporte propagadas configurables |
Solo presente si las claves configuradas están disponibles en el contexto capturado. Por defecto, solo |
Un ejemplo de una métrica con etiquetas es ipf_businessmetrics_payments_finished_total{csm="SIP", currency="CHF", direction="Outbound", htm="No", paymentType="IP SIC Outbound", localInstrument="ACTR", clientChannel="EBNKG", state="Cancelled", errorCode="RJ01"}.
Cada valor distinto para una etiqueta produce una nueva métrica distinta; por ejemplo, el ejemplo anterior es un conteo de todos Cancelled pagos.
Una métrica alternativa puede ser ipf_businessmetrics_payments_finished_total{csm="SIP", currency="CHF", direction="Outbound", htm="No", paymentType="IP SIC Outbound", localInstrument="ACTR", clientChannel="EBNKG", state="Completed", errorCode="None"} que es un recuento de todos Completed pagos.
Dado que puede haber hasta siete etiquetas diferentes, y asumiendo que cada una podría tener al menos dos valores distintos, en teoría, el número total de métricas distintas podría ser bastante grande.
En la práctica, el número de métricas puede ser menor de lo esperado porque existe una relación entre algunas etiquetas, por ejemplo, la dirección se mapea desde el tipo de pago, o quizás la moneda falta en la mayoría de los casos para Cancelled pagos
Entidad de Procesamiento
Si la entidad de procesamiento para un unit of work se conoce al producir métricas de pago, las métricas serán etiquetadas con {processingEntity="ENTITY_1"}. Si la entidad de procesamiento es desconocida para el unit of work, las métricas de pago se etiquetarán con {processingEntity="None"}.
Esta etiqueta está siempre presente en las métricas de pago.
CSM
Aplicado a métricas cuando un pago finalizado ha producido un Csm PDS objeto, p. ej.{csm="RT1"}
Esto tiene una configuración predeterminada que puede ser reconfigurada si hay un requisito específico del cliente.Csm PDS objeto.
ipf.business-metrics-processor.payment-metrics.labels {
csm {
pds-type = "Csm"
path = "/value"
}
}Tipo de Pago
Aplicado a métricas cuando un pago finalizado ha producido un PaymentType PDS objeto, p. ej.{paymentType="Debtor CT"}
Esto tiene una configuración predeterminada que puede ser reconfigurada si hay una específica para el cliente.PaymentType PDS objeto.
ipf.business-metrics-processor.payment-metrics.labels {
payment-type {
pds-type = "PaymentType"
path = "/value"
}
}State
El valor para state es el último global state para el pago final, por ejemplo.{state="Completed"}
Moneda
Aplicado a métricas cuando una moneda mapping está configurado, y la fuente configurada PDS el objeto es producido por un pago, de lo contrario el valor es "Unknown".
El valor de la etiqueta de moneda puede ser obtenido de cualquier cliente específico. PDS objeto, pero, solo una moneda mapping puede ser configurado. Un ejemplo de moneda mapping la configuración podría ser..
ipf.business-metrics-processor.payment-metrics.labels {
currency {
pdsType = ClientSpecificType
path = "/amt/pmtAmt/ccy"
}
}Dado un ClientSpecificType PDS objeto con el contenido..
{
"amt": {
"pmtAmt": {
"ccy": "EUR"
}
}
}Todas las métricas para los pagos que producen el configurado PDS el objeto será etiquetado con {currency="EUR"}.
| Si el campo de destino configurado de la PDS el objeto es nulo, la etiqueta se aplica a la métrica como "Desconocido". |
Dirección
Aplicado a métricas cuando se conoce el tipo de pago y una dirección.mapping está configurado para el tipo de pago.
Una dirección de ejemplo mapping la configuración podría ser..
ipf.business-metrics-processor.payment-metrics.labels {
direction {
payment-type-mappings = [
{
label = "Outbound"
payment-types = [ "DebtorCT1", "DebtorCT2" ]
}
{
label = "Inbound"
payment-types = [ "CreditorCT" ]
}
{
label = "AnythingYouLike"
payment-types = [ "DebtorCT3" ]
}
]
}
}Cuando se determina que un pago ha finalizado, y se sabe que el tipo de pago es "Debtor CT1", todas las métricas para ese pago se etiquetarán con {direction="Outbound"}.
Si el tipo de pago es "CreditorCT", entonces la etiqueta es {direction="Inbound"}.
| Los tipos de pago definidos en la configuración son insensibles a mayúsculas y minúsculas, por ejemplo, "debtorct1" coincide con el tipo de pago "Debtor CT1". |
HTM
Predetermina a {htm="No"}, y se establecerá en {htm="Yes"} para una métrica de pagos si ese pago vio un event que se considera un HTM event.
Un pago se considera que ha sido realizado a través de HTM si uno o más events contener la etiqueta HTM. Payment flows puede producir events con esta etiqueta, pero HTM produce su events con la etiqueta por defecto.
HTM Configuración - Obsoleto
| La siguiente configuración está obsoleta y existe únicamente por compatibilidad hacia atrás. No será compatible en una futura versión. |
Un ejemplo HTM la configuración es..
ipf.business-metrics-processor.payment-metrics.labels {
htm {
events = [ "Task Registration Successful", "Task Registration Failed" ]
}
}Si un pago finalizado produjo un event con el nombre "Task Registration Successful", entonces se considera que ha pasado por Human Task Manager, y la métrica está etiquetada con {htm="Yes"}.
Si el pago finalizado no produjo un event con uno de esos nombres, entonces el predeterminado {htm="No"} se aplica.
| El configurado event los nombres no son sensibles a mayúsculas y minúsculas ni a espacios en blanco, por ejemplo, "taskregistrationsuccessful" coincide con "Task Registration Successful". |
Instrumento Local
El localInstrument El valor de la etiqueta puede obtenerse de cualquier cliente específico. PDS objeto, pero, solo un instrumento local mapping puede ser configurado.
Un ejemplo de instrumento local mapping la configuración es..
ipf.business-metrics-processor.payment-metrics.labels {
local-instrument {
pdsType = ClientSpecificType
path = "/prcgInstrs/lclInstrm/prtry"
}
}Dado un ClientSpecificType PDS objeto con el contenido..
{
"prcgInstrs": {
"lclInstrm": {
"prtry": "ACTR"
}
}
}Todas las métricas para el pago estarán etiquetadas con {localInstrument="ACTR"}.
| Si el campo de destino configurado de la PDS el objeto es nulo, la etiqueta se aplica a la métrica como "Desconocido". |
Comparación de Identidad
El identityComparison el valor es uno de Passed|Failed|NotExecuted y se basa en el resultado de comparación de identidad más reciente para el unit of work.
El valor es NotExecuted bajo los siguientes escenarios:
-
No hay resultados de comparación de identidad para el unit of work
-
Hay un resultado de comparación de identidad, pero la etiqueta no está configurada.
-
Hay un resultado de comparación de identidad, pero la ruta de destino en el PDS el contenido no es válido
El resultado de la comparación de identidad debe estar dentro de un custom PDS objeto, y el contenido debe contener un campo booleano que indique el resultado de la comparación. Cuando el valor es true, el valor de la etiqueta es Passed, y cuando el valor es false, el valor de la etiqueta es Failed.
El resultado de la comparación puede estar dentro de cualquier custom PDS objeto, y ese campo booleano está mapeado desde su contenido a través de la configuración, por ejemplo.
ipf.business-metrics-processor.payment-metrics.labels {
identity-comparison {
pds-type = ClientSpecificPds
path = "/comparisonResult/result"
}
}Dado un ClientSpecificType PDS con el siguiente contenido..
{
"comparisonResult": {
"result": true
}
}Entonces, todas las métricas para el pago serán etiquetadas con {identityComparison="Passed"}.
| Se llama comparación de identidad aquí, lo cual se alinea con la nomenclatura del IPF para el servicio de comparación de identidad, pero los clientes pueden nombrar su variable en su Grafana tablero como comparación de acreedores. |
Canal del Cliente
El clientChannel el valor de la etiqueta puede ser obtenido de cualquier cliente específico PDS objeto, pero, solo un canal de cliente mapping puede ser configurado.
Un canal de cliente de ejemplo mapping la configuración es..
ipf.business-metrics-processor.payment-metrics.labels {
client-channel {
pdsType = ClientSpecificType
path = "/instrMsg/cstmCrdTrfInitn/chanl"
}
}Dado un ClientSpecificType PDS objeto con el contenido..
{
"instrMsg": {
"cstmCrdTrfInitn": {
"chanl": "EBNKG"
}
}
}Todas las métricas para el pago estarán etiquetadas con {clientChannel="EBNKG"}.
| Si el campo de destino configurado de la PDS el objeto es nulo, la etiqueta se aplica a la métrica como "Desconocido". |
Código de Error
El errorCode el valor se obtiene de la originalReasonCode campo dentro de un process flow event, y es el valor más reciente para un unit of work si detecta más de un error.
Si no hay ningún código de error en ninguno de los events para un unit of work entonces no hay error, y el valor de la etiqueta es "None".
Un ejemplo de esta etiqueta es {errorCode="E37:00001}, o {errorCode="None"}.
Una nota sobre el cliente PDS configuración de la ruta
Es posible configurar su PDS ruta del objeto para navegar a los campos contenidos dentro de una Lista. El Procesador de Métricas siempre intentará utilizar el primer elemento de esa lista para obtener el valor de su campo deseado.
Este cliente PDS la configuración de la ruta del objeto puede aplicarse a CSM, Tipo de Pago, Moneda, Instrumento Local, Canal del Cliente, y Comparación de Identidad configuraciones de etiquetas.
Por ejemplo, si usted configura:
ipf.business-metrics-processor.payment-metrics.labels {
client-channel {
pdsType = ClientSpecificType
path = "/instrMsg/cstmCrdTrfInitn/chanl"
}
}Dado un ClientSpecificType PDS objeto con el contenido..
{
"instrMsg": {
"cstmCrdTrfInitn": [
{
"chanl": "EBNKG"
},
{
"chanl": "GKNBE"
}
]
}
}Entonces, todas las métricas para el pago serán etiquetadas con {clientChannel="EBNKG"}.
Si el PDS El objeto contiene una lista vacía, entonces todas las métricas para el pago serán etiquetadas con {clientChannel="UNKNOWN"}.
Claves de Contexto de Soporte Propagadas Configuradas
A partir de la versión 2024. 4, el SDK de IPF es capaz de realizar la selección de versiones de flujo basada en las claves de contexto de soporte. Para facilitar la resolución de problemas, estas claves pueden incluirse como etiquetas en todas las métricas de BAM disponibles.
Una lista de claves a incluir está disponible en ipf.business-metrics-processor.propagated-context-metrics-settings.propagated-context-keys-included-as-tags.
Configurando la lista con lo siguiente..
ipf {
business-metrics-processor {
propagated-context-metrics-settings.propagated-context-keys-included-as-tags = [ipf_version_selection]
}
}Métricas de Código de Error
Métricas Disponibles
Conteo de Códigos de Error
ipf_version_selection como una etiqueta cada vez que el procesador de métricas observa el ipf_version_selection clave en el PropagatedSupportingContext PDS.La métrica ipf_businessmetrics_errorcodes_total representa un conteo de códigos de error que han sido vistos por el Procesador de Métricas IPF - un ejemplo de la métrica es ipf_businessmetrics_errorcodes_total{code="E37:00001"}.
La etiqueta del código de error se toma de un process flow events originalReasonCode campo-si un valor está presente y no está en blanco, el contador se actualiza.
La métrica siempre contiene una etiqueta de código.
Si un pago produce más de un código de error, cada instancia se cuenta. Si un pago produce códigos de error duplicados, por ejemplo, muchos events contienen el mismo código de error, cada instancia duplicada se cuenta.
| Los conteos de códigos de error se emiten de inmediato, mientras que las métricas de pago se emiten al completar el pago. Por lo tanto, las métricas de pago pueden retrasarse respecto a los conteos de códigos de error al visualizar las métricas dentro de un período de tiempo específico. |
Etiquetas
El código de error métrico está etiquetado con el código de error actual, por ejemplo.ipf_businessmetrics_errorcodes_total{code="E37:00001"}.
Cada código de error único que haya sido visto por el Procesador de Métricas IPF representa una nueva serie temporal para la métrica. |
Además de cualquier otra etiqueta aplicada a las métricas de pago, también se captura y aplica la etiqueta principal del código de error. Cuando un pago no tiene un código de error, la etiqueta se aplica con un valor de 'Ninguno'.
Versionado PDS etiquetas
Configuración
ipf.business-metrics-processor {
payment-metrics {
versioned-labels = {
csm = [
{
pds-type = "Csm",
path = "/value"
}
],
payment-type = [
{
pds-type = "PaymentType",
path = "/value"
}
],
}
}
}Cada etiqueta se asigna a una lista de versiones específicas mappings.
Si la versión no está configurada según mapping, se establece en 0.
Mapping para cada versión no necesita ser configurada-nuevo mapping solo se deberá agregar si hay un cambio en la ruta. Un entrante PDS el objeto que está siendo procesado por el procesador de métricas aplicará el mapping de la configuración con la misma versión exacta, o si esa versión no se proporciona, la versión anterior más cercana.