Métricas
Métricas de pago
Las 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 de la ruta crítica del pago y su tiempo de espera.
Cada métrica también está etiquetada; consulta la sección Labels 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 como finalizado cuando su estado global es terminal, lo cual se logra consultando la base de datos ODS para el conjunto de estados globales terminales.
Los estados terminales se almacenan en caché para evitar tener que consultar ODS para cada pago.
Duración de pago End to End
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 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 pagos (en segundos). |
Estas métricas te permiten determinar la duración media del pago, p. ej.
Duración de la ruta crítica
La métrica ipf_businessmetrics_payments_criticalpath_duration_seconds representa el tiempo que los pagos pasaron en la ruta crítica configurada.
La ruta crítica se define por un estado de inicio y uno de fin, y puede ser diferente entre distintos tipos de pago. Esta métrica solo se produce si el pago finalizado pasó por ambos estados, inicio y fin.
El metrics processor primero examinará los eventos entrantes e intentará calcular la duración de la ruta crítica a partir de aquellos eventos que estén etiquetados como CRITICAL_PATH_START y CRITICAL_PATH_END. Si no se puede determinar la duración y existe configuración heredada (ver abajo), se utilizará la configuración para calcular la duración de la ruta crítica. Si ninguno de los enfoques tiene éxito, la métrica no se publica.
Las etiquetas CRITICAL_PATH_START y CRITICAL_PATH_END pueden aparecer en eventos a través de varios flows para una unidad de trabajo. Debe haber un fin que corresponda a cada inicio.
Es posible que una unidad de trabajo inicie y finalice muchas rutas críticas. En este caso, la duración de la ruta crítica es la suma. Si rutas críticas más pequeñas ocurren dentro de una ruta crítica más grande, se usa la ruta crítica 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 pago finalizado que pasó por una ruta crítica. Si cinco pagos finalizan y tres pasaron por una ruta crítica, este contador será tres. |
|
La mayor duración de ruta crítica (en segundos). |
|
La suma de todas las duraciones de ruta crítica (en segundos). |
Estas métricas te permiten determinar la duración media de la ruta crítica, p. ej.
Configuración de ruta crítica: obsoleta
ADVERTENCIA: Esta configuración está obsoleta y existe solo por compatibilidad hacia atrás. No será compatible en una versión futura.
NOTA: Esta configuración no es necesaria si los payment flows producen eventos con etiquetas que indican el inicio y el fin 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 de la ruta crítica de los tipos de pago Debtor CT. La duración se calcula tomando la diferencia entre la marca de tiempo del Process Flow Event con status.globalStatus=Validating y la marca de tiempo del Process Flow Event con status.globalStatus=Instructing.
Duración de espera
Las métricas de duración de espera indican cuánto tiempo pasan los pagos en estados de espera predefinidos.
La métrica ipf_businessmetrics_payments_waiting_duration_seconds representa el tiempo que los pagos pasaron en estados de espera predefinidos. Normalmente se trata del tiempo que los payment flows de IPF pasan esperando a sistemas externos, como los proporcionados por el banco cliente; p. ej., cuando el payment flow hace una llamada a un sistema del banco para realizar alguna parte del procesamiento del pago.
Los estados de espera se definen en estados o eventos en los payment flows. Cuando el Metrics Processor recibe eventos (que incluyen un nuevo estado resultante) que contienen la etiqueta WAITING_DURATION, calcula el tiempo pasado en el estado resultante y lo suma con todos los demás estados de espera. Si un pago comprende muchos flows, la suma de todos los estados de espera entre flows es la duración total de espera.
Si los eventos entrantes no están etiquetados y existe configuración heredada (ver abajo), se usará la configuración para calcular la duración total de espera. Si ninguno de los enfoques tiene éxito, la métrica no se publica.
|
Ejemplo
Un pago es procesado por un único flow que puede estar en los estados [A, B, C, D, E], donde B se considera un estado de espera. El momento en que el flow de pago transita de A a B (entrando en B) es el tiempo de inicio, y el momento en que el flow de pago transita de B a C (saliendo de B) es el tiempo de fin. La diferencia entre el inicio y el fin es la duración de espera. Un pago puede ser procesado por muchos flows, cada uno con muchos posibles estados de espera. La duración de espera del pago es la suma del tiempo que pasó en todos los estados de espera. |
Esta métrica solo se produce si el pago finalizado realmente pasó tiempo esperando y, como 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 pago finalizado que pasó un tiempo distinto de cero 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 te permiten determinar la duración media de espera, p. ej. "ipf_businessmetrics_payments_waiting_duration_seconds_sum" / "ipf_businessmetrics_payments_waiting_duration_seconds_count"
Configuración de duración de espera: obsoleta
ADVERTENCIA: Esta configuración está obsoleta y existe solo por compatibilidad hacia atrás. No será compatible en una versión futura.
NOTA: Esta configuración no es necesaria si los payment flows producen eventos con etiquetas que indican los estados de espera.
La configuración de duración de espera define una lista de estados por flow que se consideran estados de espera. Estos estados coinciden con el Resulting Status y el Originating Status de dos Process Flow Events que se ingieren para un Flow 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 son Checking Bank System A y Checking Bank System B. Esto significa que, para un pago de este flow, la duración de espera es la suma de las siguientes dos Durations:
-
La Duration entre la marca de tiempo del 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 Duration entre la marca de tiempo del Process Flow Event con
status.resultingStatus=Checking Bank System By la marca de tiempo del Process Flow Event constatus.originatingStatus=Checking Bank System B
Labels
Las etiquetas se aplican a todas las métricas de pago producidas y se pueden usar para profundizar en esas métricas; p. ej., el conteo de todos los pagos finalizados que están Completed frente a Cancelled, o un conteo de todos los pagos finalizados que pasaron por el CSM RT1.
|
Valores predeterminados de etiqueta
En la mayoría de los casos se aplica un valor de etiqueta predeterminado de "Unknown" a cualquier etiqueta de métrica de pago cuyo valor no pueda determinarse para ese pago. Esto puede ocurrir cuando nunca se recibe la fuente del valor de la etiqueta, p. ej., no hay un objeto PDS |
Las métricas de pago se etiquetarán con lo siguiente…
| Label | Descripción |
|---|---|
csm |
El CSM del pago Mapeado desde un objeto PDS |
currency |
La moneda del pago Mapeado cuando se configuran los currency mappings y el objeto PDS de origen configurado es producido por un pago. |
direction |
La dirección del pago. Mapeado cuando se configuran los direction mappings y el pago produce un objeto PDS |
htm |
Indicador que señala si un pago pasó por Human Task Manager Siempre presente con un valor predeterminado de "No", y solo "Yes" cuando los pagos producen un evento que se considera un evento HTM. |
paymentType |
El tipo del pago Mapeado desde un objeto PDS |
state |
El estado global final del pago. |
localInstrument |
El instrumento local que facilita la transferencia de fondos. Mapeado cuando se configuran los local instrument mappings y el objeto PDS de origen configurado es producido por un pago. |
clientChannel |
El canal de iniciación de pago del cliente utilizado para un pago. Mapeado cuando se configuran los client channel mappings y el objeto PDS de origen configurado es producido por un pago. |
errorCode |
El código de error más reciente para una unidad de trabajo dada. Siempre presente con el valor predeterminado de "None" cuando no hay códigos de error para la unidad de trabajo. |
identityComparison |
El resultado de comparación de identidad más reciente realizado para la unidad de trabajo Mapeado cuando se configuran identity comparison mappings y el objeto PDS de origen configurado que contiene un valor booleano true/false, match/no-match es producido por un pago. Siempre presente con el valor predeterminado de "NotExecuted" si no se realizaron comparaciones. |
processingEntity |
La entidad de procesamiento para la unidad de trabajo Siempre presente con el valor predeterminado de "None" si no hay una entidad de procesamiento conocida |
configurable propagated supporting context keys |
Solo presente si las claves configuradas están disponibles en el contexto capturado. De forma predeterminada, únicamente la clave |
Un ejemplo de 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 métrica distinta, p. ej., el ejemplo anterior es un conteo de todos los pagos Cancelled.
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 conteo de todos los pagos Completed.
Dado que puede haber hasta siete etiquetas diferentes, y suponiendo 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; p. ej., la direction se mapea desde el payment type, o quizás falta la currency en la mayoría de los casos para pagos Cancelled.
Processing Entity
Si se conoce la entidad de procesamiento para una unidad de trabajo al producir métricas de pago, las métricas serán etiquetadas con {processingEntity="ENTITY_1"}. Si la entidad de procesamiento es desconocida para la unidad de trabajo, las métricas de pago se etiquetarán con {processingEntity="None"}.
Esta etiqueta siempre está presente en las métricas de pago.
CSM
Se aplica a métricas cuando un pago finalizado ha producido un objeto PDS Csm, p. ej. {csm="RT1"}
Tiene una configuración predeterminada que puede reconfigurarse si hay un objeto PDS Csm específico del cliente.
ipf.business-metrics-processor.payment-metrics.labels {
csm {
pds-type = "Csm"
path = "/value"
}
}Payment Type
Se aplica a métricas cuando un pago finalizado ha producido un objeto PDS PaymentType, p. ej., {paymentType="Debtor CT"}
Tiene una configuración predeterminada que puede reconfigurarse si hay un objeto PDS PaymentType específico del cliente.
ipf.business-metrics-processor.payment-metrics.labels {
payment-type {
pds-type = "PaymentType"
path = "/value"
}
}State
El valor para state es el último estado global para el pago finalizado, p. ej., {state="Completed"}
Currency
Se aplica a métricas cuando hay una configuración de currency mapping y el objeto PDS de origen configurado es producido por un pago; de lo contrario, el valor es "Unknown".
El valor de la etiqueta currency puede obtenerse de cualquier objeto PDS específico del cliente, pero solo se puede configurar un currency mapping. Un ejemplo de configuración de mapeo de currency podría ser…
ipf.business-metrics-processor.payment-metrics.labels {
currency {
pdsType = ClientSpecificType
path = "/amt/pmtAmt/ccy"
}
}Dado un objeto PDS ClientSpecificType con el contenido…
{
"amt": {
"pmtAmt": {
"ccy": "EUR"
}
}
}Todas las métricas para pagos que produzcan el objeto PDS configurado se etiquetarán con {currency="EUR"}.
NOTA: Si el campo de destino configurado del objeto PDS es null, la etiqueta se aplica a la métrica como "Unknown".
Direction
Se aplica a métricas cuando el tipo de pago es conocido y existe una configuración de direction mapping para el tipo de pago.
Un ejemplo de configuración de direction mapping 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 determine que un pago ha finalizado y se conozca que el tipo de pago es "DebtorCT1", todas las métricas para ese pago se etiquetarían con {direction="Outbound"}.
Si el tipo de pago es "CreditorCT", entonces la etiqueta es {direction="Inbound"}.
NOTA: Los tipos de pago definidos en la configuración no distinguen mayúsculas/minúsculas, p. ej., "debtorct1" coincide con el tipo de pago "DebtorCT1".
HTM
De manera predeterminada {htm="No"}, y se establecerá en {htm="Yes"} para las métricas de un pago si ese pago vio un evento que se considera un evento HTM.
Se considera que un pago ha pasado por HTM si uno o más eventos contienen la etiqueta HTM. Los payment flows pueden producir eventos con esta etiqueta, pero HTM produce sus eventos con la etiqueta por defecto.
Configuración de HTM: obsoleta
ADVERTENCIA: La siguiente configuración está obsoleta y existe solo por compatibilidad hacia atrás. No será compatible en una versión futura.
Un ejemplo de configuración de HTM es…
ipf.business-metrics-processor.payment-metrics.labels {
htm {
events = [ "Task Registration Successful", "Task Registration Failed" ]
}
}Si un pago finalizado produjo un evento con el nombre "Task Registration Successful", entonces se considera que pasó por Human Task Manager, y la métrica se etiqueta con {htm="Yes"}.
Si el pago finalizado no produjo un evento con uno de esos nombres, entonces se aplica el valor predeterminado {htm="No"}.
NOTA: Los nombres de eventos configurados no distinguen mayúsculas/minúsculas ni espacios en blanco; p. ej., "taskregistrationsuccessful" coincide con "Task Registration Successful".
Local Instrument
El valor de la etiqueta localInstrument puede obtenerse de cualquier objeto PDS específico del cliente, pero solo se puede configurar un local instrument mapping.
Un ejemplo de configuración de local instrument mapping es…
ipf.business-metrics-processor.payment-metrics.labels {
local-instrument {
pdsType = ClientSpecificType
path = "/prcgInstrs/lclInstrm/prtry"
}
}Dado un objeto PDS ClientSpecificType con el contenido…
{
"prcgInstrs": {
"lclInstrm": {
"prtry": "ACTR"
}
}
}Todas las métricas para el pago se etiquetarán con {localInstrument="ACTR"}.
NOTA: Si el campo de destino configurado del objeto PDS es null, la etiqueta se aplica a la métrica como "Unknown".
Identity Comparison
El valor de identityComparison es uno de Passed|Failed|NotExecuted y se basa en el resultado de comparación de identidad más reciente para la unidad de trabajo.
El valor es NotExecuted en los siguientes casos:
-
No hay resultados de comparación de identidad para la unidad de trabajo
-
Existe un resultado de comparación de identidad, pero la etiqueta no está configurada
-
Existe un resultado de comparación de identidad, pero la ruta de destino en el contenido del PDS no es válida
El resultado de la comparación de identidad debe estar dentro de un objeto PDS personalizado 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 objeto PDS personalizado y ese campo booleano se mapea desde su contenido mediante configuración, p. ej.
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 se etiquetarán con {identityComparison="Passed"}.
NOTA: Se llama identity comparison aquí, lo cual se alinea con la nomenclatura de IPF del servicio de comparison de identidad, pero los clientes pueden nombrar su variable en su dashboard de Grafana como creditor comparison.
Client Channel
El valor de la etiqueta clientChannel puede obtenerse de cualquier objeto PDS específico del cliente, pero solo se puede configurar un client channel mapping.
Un ejemplo de client channel mapping es…
ipf.business-metrics-processor.payment-metrics.labels {
client-channel {
pdsType = ClientSpecificType
path = "/instrMsg/cstmCrdTrfInitn/chanl"
}
}Dado un objeto PDS ClientSpecificType con el contenido…
{
"instrMsg": {
"cstmCrdTrfInitn": {
"chanl": "EBNKG"
}
}
}Todas las métricas para el pago se etiquetarán con {clientChannel="EBNKG"}.
NOTA: Si el campo de destino configurado del objeto PDS es null, la etiqueta se aplica a la métrica como "Unknown".
Error Code
El valor de errorCode se obtiene del campo originalReasonCode dentro de un process flow event, y es el valor más reciente para una unidad de trabajo si se observan varios errores.
Si no hay código de error en ninguno de los eventos de una unidad de trabajo, entonces no hay error y el valor de la etiqueta es "None".
Un ejemplo de esta etiqueta es {errorCode="E37:00001} o {errorCode="None"}.
Nota sobre la configuración de ruta de PDS de cliente
Es posible configurar la ruta de tu objeto PDS para navegar a campos contenidos dentro de una lista (List). El Metrics Processor siempre intentará usar el primer elemento de esa lista para obtener el valor del campo deseado.
Esta configuración de ruta de objeto PDS de cliente puede aplicarse a CSM, Payment Type, Currency, Local Instrument, Client Channel, y Identity Comparison.
Por ejemplo, si configuras:
ipf.business-metrics-processor.payment-metrics.labels {
client-channel {
pdsType = ClientSpecificType
path = "/instrMsg/cstmCrdTrfInitn/chanl"
}
}Dado un objeto PDS ClientSpecificType con el contenido…
{
"instrMsg": {
"cstmCrdTrfInitn": [
{
"chanl": "EBNKG"
},
{
"chanl": "GKNBE"
}
]
}
}Entonces todas las métricas para el pago se etiquetarán con {clientChannel="EBNKG"}.
Si el objeto PDS contiene una lista vacía, entonces todas las métricas para el pago se etiquetarán con {clientChannel="UNKNOWN"}.
Configured Propagated Supporting Context Keys
A partir del lanzamiento 2024.4, IPF SDK es capaz de realizar la selección de versión de flow basada en claves de supporting context. Para facilitar la resolución de problemas, estas claves pueden incluirse como etiquetas en todas las métricas 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.
Configurar la lista con lo siguiente…
ipf {
business-metrics-processor {
propagated-context-metrics-settings.propagated-context-keys-included-as-tags = [ipf_version_selection]
}
}…dará como resultado la inclusión de ipf_version_selection como etiqueta siempre que el metrics processor observe la clave ipf_version_selection en el PropagatedSupportingContext PDS.
Métricas de códigos de error
Métricas disponibles
Conteo de códigos de error
La métrica ipf_businessmetrics_errorcodes_total representa un conteo de códigos de error que han sido vistos por IPF Metrics Processor; un ejemplo de la métrica es ipf_businessmetrics_errorcodes_total{code="E37:00001"}.
La etiqueta del código de error se toma del campo originalReasonCode de un process flow event; si hay un valor presente y no está en blanco, se actualiza el contador.
La métrica siempre contiene una etiqueta code.
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, p. ej., muchos eventos contienen el mismo código de error, cada instancia duplicada se cuenta.
NOTA: Los conteos de códigos de error se emiten inmediatamente, mientras que las métricas de pago se emiten al completarse el pago. Por lo tanto, las métricas de pago pueden ir por detrás de los conteos de códigos de error cuando se visualizan las métricas dentro de un periodo de tiempo específico.
Labels
La métrica de código de error se etiqueta con el código de error real, p. ej., ipf_businessmetrics_errorcodes_total{code="E37:00001"}.
|
Cada código de error único, una vez visto por IPF Metrics Processor, 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 de código de error. Donde un pago no tiene un código de error, la etiqueta aún se aplica con un valor de 'None'