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 como finalizado cuando su estado global es terminal; esta información se proporciona en los eventos recibidos 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 duración de pago más larga (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 estado de inicio y un estado final, y puede ser diferente entre los diferentes tipos de pago.
Esta métrica solo se produce si el pago finalizó tanto en el estado de inicio como en el estado de fin.
El procesador de métricas primero examinará los eventos entrantes y intentará calcular la duración de la ruta crítica a partir de aquellos eventos 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 publica.
El CRITICAL_PATH_START, y CRITICAL_PATH_END Las etiquetas pueden aparecer en eventos a través de flujos para una unidad de trabajo.
Debe haber un final que coincida con cada inicio.
Es posible que una unidad de trabajo inicie y finalice muchos caminos críticos. En este caso, la duración de la ruta crítica es la suma. Si se producen rutas críticas más pequeñas dentro de una ruta crítica más grande, se utiliza 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 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 produzca eventos con etiquetas que indiquen 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 permanecen 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 momento en 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 eventos en payment flows.
Cuando el Procesador de Métricas recibe eventos (que incluyen un nuevo estado resultante) que contienen la etiqueta WAITING_DURATION, calcula el tiempo transcurrido en el estado resultante y lo suma 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 los eventos entrantes no están etiquetados y existe una configuración heredada (véase más abajo), se utilizará 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 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. 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 la hora de inicio y la hora 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 produzca eventos con etiquetas que indiquen 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 del 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 del 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 |
Una bandera que indica si un pago se realizó con éxito. Human Task Manager Siempre presente con un valor predeterminado de "No", y solo "Sí" cuando los pagos producen un evento que se considera un HTM evento. |
paymentType |
El tipo de pago Mapeado de un |
estado |
El estado global final 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 una unidad de trabajo dada. Siempre presente con un valor predeterminado de "Ninguno" cuando no hay códigos de error para la unidad de trabajo. |
identityComparison |
El resultado más reciente de la comparación de identidades realizado para la unidad de trabajo 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 la unidad de trabajo 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 una unidad de trabajo es conocida 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
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 el estado es el último estado global para el pago finalizado, 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 ", todos los métricas para ese pago estarían etiquetadas 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 evento que se considera un HTM evento.
Un pago se considera que ha sido realizado a través de HTM si uno o más eventos contienen la etiqueta HTM.
Los flujos de pago pueden producir eventos con esta etiqueta, pero HTM produce sus eventos 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 evento 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 evento con uno de esos nombres, entonces el valor predeterminado {htm="No"} se aplica.
| Los nombres de eventos configurados son insensibles a mayúsculas y minúsculas, así como a los espacios en blanco; por ejemplo, "taskregistrationsuccessful" coincide con "Task Registration Successful". |
Instrumento Local
El localInstrument El valor de la etiqueta puede ser obtenido 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 más reciente de comparación de identidad para la unidad de trabajo.
El valor es NotExecuted bajo los siguientes escenarios:
-
No hay resultados de comparación de identidad para la unidad de trabajo.
-
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 denomina comparación de identidades aquí, lo cual se alinea con la nomenclatura del servicio de comparación de identidades del IPF, pero los clientes pueden nombrar su variable según 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 del 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 evento de flujo de proceso, y es el valor más reciente para una unidad de trabajo si se detectan más de un error.
Si no hay ningún código de error en ninguno de los eventos para 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"}.
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 siempre que el procesador de métricas observe 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 los eventos del flujo de proceso.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 eventos 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. Los métricas de pago pueden, por lo tanto, seguir 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 aún 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"
}
],
currency =[
{
pds-type = "SomeDefaultType"
path = "/pdsType/ccy"
},
{
version = 2
pds-type = "CurrencyType"
path = "/currency/v2/ccy"
},
{
version = 4
pds-type = "UpdatedCurrencyType"
path = "/currency/v5/ccy"
}
]
}
}
}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.
No es necesario configurar el mapeo para cada versión.- nuevo mapping solo se deberá añadir 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.
En el ejemplo anterior, si no había una versión para una moneda PDS objeto, tomaríamos el camino desde " someDefaultType ", lo mismo ocurriría si tuviéramos una moneda de versión 1" PDS objeto. Una moneda de versión 2 PDS el objeto tomaría el " CurrencyType " mapping, como lo haría una moneda de versión 3 PDS objeto. Una moneda de versión 4 PDS el objeto tomaría el " UpdatedCurrencyType " mapping, como lo harían cualquier versión superior.