Monitoreo y Observabilidad

La estrategia sobre IPF para el monitoreo y la observabilidad se logra mediante la utilización de un event paradigma impulsado, categorización estricta del comportamiento de la aplicación y extensibilidad para exponer estos datos a través de canales apropiados, con las mejores herramientas.

Monitoreo de IPF application Los servicios pueden realizarse de tres maneras principales:

  • HTTP APIs

  • Métricas de series temporales a través de Prometheus y Grafana

  • Registro de aplicaciones

Fuera de Alcance:

  • Monitoreo del rendimiento de aplicaciones (APM)- Esto es algo a considerar si dicho software está disponible en el customer’s site. El software APM como Dynatrace o AppDynamics puede ayudar a diagnosticar problemas potenciales antes de que se materialicen.

  • Monitoreo de Infraestructura, p. ej., Corredores, contenedores

Definiciones

El " IPF application "está compuesto en realidad por múltiples paquetes de software en tiempo de ejecución." Esta sección describirá la terminología que se utilizará en este documento:

Componente A veces conocido como Descripción Necesita estar en Akka cluster¿con otros nodos similares?

Servicios de Pago (Customised)

Escriba al lado

El conjunto de payment flows que el cliente ha definido.

Puede haber múltiples de estos que representan diferentes conjuntos de flujos (por ejemplo, transferencia de crédito, recuperación, servicio de valor añadido).

Sí

CSM Service

CSM Pack,Scheme Pack

Un adaptador para un proveedor de pagos, como un esquema de pago, billetera, etc.

No

Servicios de Soporte

Servicio de Notificación

Procesamiento adicional de events a sistemas de terceros.

Sí

Servicio Individual APIs(HTTP)

Hay ciertos HTTP APIs que están habilitados por defecto y que pueden ser interrogados cuando la aplicación está en ejecución, cada uno sirviendo a un propósito específico.

Aquí tiene un resumen de esos APIs y los elementos de configuración que establecen sus nombres de host y puertos:

¿Qué es? ¿Qué hace? Caso de uso de ejemplo Referencia de API (o similar) Nombre de host predeterminado Puerto predeterminado Anular variable de entorno del host Variable de entorno de anulación de puerto Disponible en

Spring Boot Actuador API

Spring Boot métricas de estilo para el JVM, propiedades de configuración de Spring,beans, salud

Para verificar la versión de las bibliotecas activas

Haga clic aquí

0. 0. 0. 0

8080

MANAGEMENT_SERVER_ADDRESS

MANAGEMENT_SERVER_PORT(set to -1 para deshabilitar)

  • Implementación(es) del Cliente

  • Conector de Esquema

Cluster de Gestión de Akka HTTP API

Información sobre el funcionamiento actual Akka cluster para fines de depuración

Para verificar el clúster state y gestionar nodos manualmente

Haga clic aquí

(the result of InetAddress.getLocalHost().getHostAddress() que suele-pero no siempre - 127. 0. 0. 1)

8558

AKKA_MANAGEMENT_HTTP_HOSTNAME

AKKA_MANAGEMENT_HTTP_PORT

  • Implementación(es) del Cliente

Spring Boot Actuador API

Utilice esto API para consultar sobre la Primavera ApplicationContext que actualmente se está ejecutando en este nodo en particular. Algunos puntos finales interesantes de Spring Actuator para IPF:

  • conditions Verifique que el lado de escritura y lectura de la aplicación se haya configurado correctamente en los nodos relevantes.

  • env: Muestre las variables de entorno para verificar que las sobreescrituras son correctas

  • health: Útil para sondas de actividad y similares

  • info: Información general de la aplicación (también útil para las pruebas de actividad)

Hay más puntos finales disponibles. Visite el Spring Boot Consulte el enlace del actuador en la tabla anterior para ver todos los detalles. Además, por favor tenga en cuenta esto sección particular sobre cómo habilitar y deshabilitar endpoints de Actuator particulares MANAGEMENT_ENDPOINT_X_ENABLED donde X es la parte del Actuador relevante).

Para obtener información sobre cómo configurar TLS para los puntos finales del Actuator, consulte esta sección.

Akka Cluster HTTP Gestión

Este API permite al usuario interactuar con el IPF subyacente Akka cluster usando un HTTP interfaz.

El uso principal para esto API es verificar el clúster state. Los componentes de implementación del cliente IPF requieren que todos los nodos de "escritura" que sirven al mismo conjunto de flujos (por ejemplo, transferencia de crédito, recuperación, pago de billetera digital) estén en un Akka cluster juntos. Si este no es el caso, no se aceptará nuevo trabajo para evitar la pérdida de transacciones.

El clúster encuentra otros nodos similares por sí mismo, pero en caso de que la aplicación no parezca estar consumiendo ningún trabajo nuevo, este debe ser el primer punto de consulta para asegurar que el clúster esté en un estado válido.state y que la aplicación no se encuentra en un "cerebro dividido" (múltiples nodos siendo creados en clústeres separados).

Las situaciones de cerebro dividido pueden resolverse utilizando el Akka Resolutor de Cerebro Dividido. Se puede encontrar más información sobre este tema en el Sitio web de Akka.

El Akka Cluster HTTP El endpoint de gestión también permite operaciones de actualización. Si este comportamiento no es deseado, establezca el AKKA_MANAGEMENT_READ_ONLY`variable de entorno para `true para habilitar el modo de solo lectura donde la información del clúster solo puede ser recuperada pero no actualizada.

Configuración de TLS para Akka La gestión es la misma que la de Spring Boot, pero el server or management.server los prefijos son reemplazados por akka.management. Por lo tanto, por ejemplo, para establecer la ruta del almacén de claves, la propiedad sería akka.management.ssl.keystore`or `AKKA_MANAGEMENT_SSL_KEYSTORE(the Spring Boot equivalente siendo server.ssl.keystore o SERVER_SSL_KEYSTORE).

Métricas de Series Temporales

Las métricas se exponen a través de una Prometheus HTTP servidor que es interrogado en un intervalo de tiempo determinado por Prometheus, y visualizado utilizando herramientas como Grafana y Kibana.

El componente AlertManager realiza una agregación configurable de events basado en umbrales y condiciones para traducir este comportamiento del sistema en algo que puede requerir acción por parte de un Operador.

monitoring

Métricas de Aplicación Relevantes

Las métricas agregadas a nivel de aplicación también se exponen con el mismo mecanismo:

Nombre de la métrica Tipo Descripción Información del evento Fuente

ipf_behaviour_end_to_end_latency_seconds_bucket

Histograma

Tiempo en segundos que toma la ejecución de un flujo

behaviour - IPF flow nombre,event - tiempo transcurrido desde el inicio del flujo hasta esto event,type - uno de los siguientes CSM_STATES_ONLY,NO_CSM_STATES or FULL_FLOW

Spring Actuator (TCP/8080)

ipf_behaviour_end_to_end_latency_seconds_count

Contador

Número total de invocaciones

mismos etiquetas que se utilizan en ipf_comportamiento_latencia_final_a_final_segundos_cubo

Spring Actuator (TCP/8080)

ipf_behaviour_end_to_end_latency_seconds_sum

Contador

Tiempo total gastado por todas las invocaciones

mismos etiquetas que se utilizan en ipf_comportamiento_latencia_final_a_final_segundos_balde

Spring Actuator (TCP/8080)

ipf_behaviour_per_state_latency_seconds_bucket

Histograma

Tiempo dedicado por los flujos en eso state

behaviour - El nombre del flujo,status - estado

Spring Actuator (TCP/8080)

ipf_behaviour_per_state_latency_seconds_count

Contador

Número total de llamadas a eso state

behaviour - El nombre del flujo,status - estado

Spring Actuator (TCP/8080)

ipf_behaviour_per_state_latency_seconds_sum

Contador

Tiempo dedicado por todas las llamadas a eso state

behaviour - El nombre del flujo,status - estado

Spring Actuator (TCP/8080)

ipf_behaviour_flows_in_state

Medidor

Número de flujos activos por state

behaviour - El nombre del flujo,status - estado

Spring Actuator (TCP/8080)

ipf_behaviour_command_processing_times

Histograma

Tiempos desde el momento en que IPF recibe un comando hasta que se completan todos los efectos secundarios.

Segmentado por comportamiento, nombre del comando, anterior state, resultando state, resultado de la llamada (éxito, fracaso)

Esta métrica está desactivada por defecto debido a la gran cantidad de memoria que consume en altas cargas y al utilizar ZGC. Puede habilitar este informe de métricas configurando ipf.behaviour.metrics.processing-time-metrics-enabled = true in la aplicación, pero debe asegurarse de que ZGC no esté en uso y de que haya suficiente memoria del sistema.

Spring Actuator (TCP/8080)

ipf_behaviour_input_handling_overall

Histograma

Hora de realizar una llamada a IPF, incluyendo event tiempo de persistencia, ejecución de todos los efectos secundarios y posibles reintentos

Segmentado por comportamiento, nombre del comando, resultado de la llamada (éxito/fallo)

Esta métrica está desactivada por defecto debido a la gran cantidad de memoria que consume en altas cargas y al utilizar ZGC. Puede habilitar este informe de métricas configurando ipf.behaviour.metrics.processing-time-metrics-enabled = true in la aplicación, pero debe asegurarse de que ZGC no esté en uso y de que haya suficiente memoria del sistema.

Spring Actuator (TCP/8080)

flow_started_total

Contador

Se han creado (iniciado) un número de transacciones.

behaviour - El nombre del flujo,description - mismo que behaviour

Spring Actuator (TCP/8080)

flow_finished_total

Contador

Número de transacciones que han alcanzado un terminal (final)state

behaviour - El nombre del flujo,description - mismo que behaviour,reasonCode - reasonCode utilizado en final state,state - nombre del terminal state

Spring Actuator (TCP/8080)

state_timeout_total

Contador

Número de flujos que han generado un tiempo de espera system event

behaviour - El nombre del flujo,description - state que ha expirado

Spring Actuator (TCP/8080)

action_invoked_total

Contador

Se genera cuando el dominio IPF invoca una acción en un sistema externo.

behaviour - El nombre del flujo,description - nombre de la acción llamada

Spring Actuator (TCP/8080)

action_timeout_total

Contador

Se genera cuando una acción invocada por IPF no ha recibido una respuesta dentro del tiempo de espera configurado.

behaviour - El nombre del flujo,description - nombre de la acción llamada

Spring Actuator (TCP/8080)

domain_event_persisted_total

Contador

Se genera cuando un Domain Event ha sido persistido con éxito

behaviour - El nombre del flujo,description - event nombre

Spring Actuator (TCP/8080)

unexpected_command_total

Contador

Se genera cuando el dominio IPF recibe un comando que no puede ser manejado en el actual state del agregado

command_name - El nombre del comando,status - estado del flujo cuando se recibe el comando

Spring Actuator (TCP/8080)

ipf_processing_data_journal_latency_seconds_bucket

Histograma

que registra la duración entre el momento en que un domain event ha sido creado y el tiempo que ha sido enviado a ODS; las duraciones serán sensibles a la desviación temporal entre los servidores, por lo que deben ser tratadas únicamente como estimaciones.

Spring Actuator (TCP/8080)

ipf_processing_data_journal_latency_seconds_count

Contador

Conteo del número total de domain events enviado a ODS

ipf_processing_data_journal_latency_seconds_sum

Contador

Tiempo total empleado para enviar domain events to ODS
Tipo Uso

CSM_STATES_ONLY

Registra únicamente el tiempo dedicado a CSM-estados relacionados (por ejemplo, compensación y liquidación, solicitud de estado, etc.)

NO_CSM_STATES

Registra el tiempo entre el primero y el último event en el flujo, menos el tiempo gastado in CSM- estados relacionados (por ejemplo, compensación y liquidación, solicitud de estado, etc.)

FULL_FLOW

Registra el tiempo entre el primero y el último event en el flujo

Spring Boot Tableros de control

Básico JVM métricas a través de la prometheus Spring Boot Punto final del actuador. Hay varios paneles que pueden ser utilizados para visualizar estos datos, pero recomendamos este desde el Grafana colección de paneles de control.

Akka Tableros de control

Hay algunas soluciones listas para usar. Grafana métricas que están disponibles para Akka, documentado y disponible para descargar aquí. Lo interesante Akka tableros de control a tener en cuenta-en lo que respecta a IPF - are:

  • Evento Sourced Behaviours: Métricas sobre events y comando siendo procesado por IPF flows

  • Akka Streams y Akka Streams Métricas de rendimiento del procesamiento de flujos de conectores

Tableros Específicos de IPF

También hay algunos custom Tableros específicos de IPF que están disponibles:

Nombre Descripción Datos Requeridos

IPF Connectors

Estadísticas por conector sobre el número de solicitudes enviadas, recibidas y los tiempos de respuesta promedio por conector.

IPF Flow Timings

Estadísticas por flujo sobre cuánto tiempo tardan los flujos en ser procesados desde la iniciación hasta que alcanzan un final.state.

IPF Resilience4j

Informa estadísticas sobre los interruptores de circuito del conector utilizando métricas definidas en Resilience4J.

IPF JVM Overview

Proporciona algunas estadísticas sobre el JVM, por ejemplo, la memoria heap, por pod en el clúster. Para un panel de control más detallado, consulte IPF JVM (Actuator)

IPF CSM Simulator

Informes sobre cualquier métrica de solicitud/respuesta de CSM simuladores que están desplegados en el clúster.

Requiere un namespace etiqueta en Prometheus

IPF Node Degradation

Informes sobre una amplia gama de métricas de servicio de aplicaciones (MongoDB/Akka..) para determinar la salud general del ecosistema de IPF y ayudar a identificar si ha habido alguna degradación del rendimiento a lo largo del tiempo.

IPF ODS Ingestion

Estadísticas relacionadas con el ODS ingestion informe de servicio sobre cualquier retraso entre la ingestión de datos así como métricas relacionadas con Kafka/MongoDB.

Se asume que el nombre del pod es ods-ingestion.

Kafka se asume que el grupo de consumidores para la entrada se llama ipf-processing-data-ingress-consumer-group.

Kafka se asume que el tema de salida se llama IPF_PROCESSING_DATA.

IPF Transaction Status

Informes sobre estadísticas basadas en métricas de flujo para mostrar transacciones en estados completados o no completados.

Finalización state el nombre se asume que termina con la palabra Completed o de lo contrario todo events terminará en el panel Rechazado

IPF ESB Actions & Inputs

Informes sobre Event Sourced Behaviours métricas de acción y entrada de (ESBs) que proporcionan la tasa de ejecución entre estas funciones.

IPF JVM (Actuator)

Proporciona estadísticas detalladas sobre el JVM de las métricas proporcionadas por el actuador de Spring.

IPF Requests Info

Proporciona métricas generales y por conector sobre los tiempos de solicitud y respuesta.

Requiere un namespace etiqueta en Prometheus

Ejemplo de trabajo de uso de PromQL para generar un Custom Gráfico

Requisito

Un gráfico circular para representar todos los CSM estados de finalización de todas las transacciones que ocurrieron en este día calendario y que tomaron menos del SLA de 5 segundos.
— Business Analyst

Paso 1 - Elección de Métrica

Primero debe encontrar la métrica más cercana que proporcione los datos requeridos, en este caso la ipf_behaviour_end_to_end_latency_seconds los datos del histograma deben funcionar.

sum by(event) (
 increase(
  ipf_behaviour_end_to_end_latency_seconds_bucket{type="CSM_STATES_ONLY", service=~".*creditor.*", le="5. 0"}[15m]
 )
)

Esta consulta devolverá el número de estados completados en intervalos de 15 minutos agrupados por event

  • increase- calcula el aumento en la serie temporal en el vector de rango

  • sum - calcula el total en la serie temporal

Se pueden encontrar más funciones de PromQL que se pueden utilizar.https://prometheus.io/docs/prometheus/latest/querying/functions[aquí].

step2

Paso 2 - Agrupación en Días

Ahora puede crear un diario hoy con la siguiente consulta.

last_over_time(
 sum by(event) (
  increase(
   ipf_behaviour_end_to_end_latency_seconds_bucket{type="CSM_STATES_ONLY", service=~".*creditor.*", le="5. 0"}[1d] offset -1d
   )
  )
[1d:1d]
)

  • last_over_time- el valor de punto más reciente en el intervalo especificado

step1

Paso 3 - Limitar a un Solo Día

Alterar el panel de Query options para añadir un relative time de now/d

step3

Paso 4 - Cambie el Estilo del Gráfico

Utilizando el selector de visualización en el lado derecho, elija el Pie Chart opción, y alterar el Title to Calls to Scheme. También podrá añadir los siguientes cambios:

step4a

  • Añada etiquetas de gráfico de sectores de Name

  • Cambie el modo de leyenda a Table, establezca la colocación en Right y añada Valores de Etiqueta de Percent y Value

Ahora puede guardar el panel, que luego se verá algo como

step4b

Configuración del Exportador

 Spring Boot Las métricas del actuador se exponen a través del mismo actuador. HTTP servidor documentado arriba.
Consulte arriba para saber cómo cambiar el host y el puerto del Actuator.

Ambos Akka y específico de IPF Prometheus las métricas están disponibles en el mismo Prometheus servidor web de exportación, que por defecto está configurado para escuchar en todas las interfaces (0. 0. 0. 0) y puerto 9001. Para cambiar estos detalles, las variables de entorno relevantes son:

  • CINNAMON_PROMETHEUS_HTTP_SERVER_HOST

  • CINNAMON_PROMETHEUS_HTTP_SERVER_PORT

Si se cambian estas propiedades, recuerde también cambiar el Prometheus lado para que Prometheus puede recopilar datos de series temporales de la(s) dirección(es) correcta(s).

Registro

IPF utiliza Logback para la configuración de registro. Esto permite al usuario configurar una instalación de registro que puede reflejar la de otras aplicaciones desarrolladas dentro de la organización y hacer que IPF informe los datos de registro de la misma manera.

Este documento explicará algunas configuraciones de registro típicas que pueden utilizarse para generar datos de registro de diversas maneras.

Para todas las configuraciones, el archivo de configuración de Logback debe estar montado en el classpath de la aplicación. Para una imagen construida con Icon, esto siempre está disponible en /[name of container]/conf. Así que si el contenedor se llama credit-transfer, entonces la configuración de Logback puede ser montada en /credit-transfer/conf/logback.xml.

Opción 1: Elasticsearch/Logstash/Kibana

Una pila popular en la industria es ELK: una combinación de Elasticsearch, Logstash (y/o Beats) y Kibana. Anteriormente se conocía como la pila ELK, pero con la introducción de Beats, Elastic ha estado promoviendo la denominación más genérica de "Elastic Stack" para esta configuración.

De cualquier manera, la configuración se ve así:

elk

Primero necesitamos configurar Logstash para que escuche en un puerto TCP. Aquí tiene un ejemplo de cómo configurar eso en Logstash:

input {
    tcp {
        port => 4560
        codec => json_lines
    }
}

Esto hace que Logstash escuche en el puerto 4560 por líneas de JSON separado por el carácter de nueva línea \n. El appender Logback de Logstash hace esto por nosotros y puede ser configurado de la siguiente manera:

<? xml version="1. 0" encoding="UTF-8"?>
<configuration>
  <appender name="stash" class="net.logstash.logback.appender. LogstashAccessTcpSocketAppender">
      <destination>127. 0. 0. 1:4560</destination>
      <encoder class="net.logstash.logback.encoder. LogstashAccessEncoder" />
  </appender>

  <appender-ref ref="stash" />
</configuration>

Esto configurará IPF application registros que deben ser enviados a Logstash. Configurar Logstash para conectarse a Elasticsearch (y Kibana a Elasticsearch) está fuera del alcance de este documento, pero puede encontrarse en el sitio web de Elastic.https://www.elastic.co/start[aquí].

Más ejemplos, incluyendo:

  • Configurando TLS sobre la conexión TCP, y;

  • Una variante UDP del appender

Se puede encontrar en la página de GitHub del appender Logstash Logback.https://github.com/logstash/logstash-logback-encoder[aquí].

Configurando un Appender de Logstash para System Events

Si desea agregar IPF system events, considere utilizar el com.iconsolutions.payments.systemevents.utils. Slf4jEventLogger que reenvía todo lo recibido system events a un appender. Esto puede ser utilizado en conjunto con este appender de Logstash para enviar system events a un agregador como Elasticsearch mencionado anteriormente.

Aquí tiene un ejemplo de configuración de Logback que toma Slf4jEventLogger events y los envía a nuestro STASH appender:

<logger name="com.iconsolutions.payments.systemevents.utils. Slf4jEventLogger" level="DEBUG" additivity="false">
    <appender-ref ref="STASH"/>
</logger>

Opción 2: Splunk

Aparte de una configuración específica como la mencionada anteriormente, una verdadera aplicación de doce factores debe generar sus registros.- sin búfer-to stdout, y esto puede ser analizado por software como Splunk.

splunk

Splunk proporciona un HTTP apéndice para Logback. Esto está documentado aquí. Ese documento también describe algunas consideraciones de rendimiento para el registro con HTTP, y también un appender TCP que puede ser utilizado en lugar de HTTP.

La plantilla de Logback mencionada en ese documento se puede encontrar aquí.

Hay tres campos obligatorios:

  • url: La URL de Splunk a la que debe reenviar

  • token: El token proporcionado por Splunk para la autenticación y autorización

  • index: El índice de Splunk (repositorio) para almacenar estos datos de registro

Opción 3: Archivos (No Recomendado)

 Registrar en un archivo rompe los principios nativos de la nube sobre no hacer suposiciones acerca de un sistema de archivos subyacente.
Los registros deben ser tratados como flujos de datos en lugar de archivos que necesitan mantenimiento.

Utilice este enfoque únicamente como último recurso cuando no sea absolutamente posible emplear un enfoque más moderno para el registro. Para más información, por favor consulte XI. Registros sobre la aplicación de Doce Factores.

Es posible especificar un appender de archivo Logback normal. Un típico logback.xml podría verse así:

logback.xml
<? xml version="1. 0" encoding="UTF-8" scan="true"?>
<configuration>
    <jmxConfigurator />
    <appender name="FILE"
              class="ch.qos.logback.core.rolling. RollingFileAppender">
        <file>/opt/ipf/logs/credit-transfer-service.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling. FixedWindowRollingPolicy">
            <fileNamePattern>/opt/ipf/logs/credit-transfer-service.log.%i</fileNamePattern>
            <minIndex>1</minIndex>
            <maxIndex>20</maxIndex>
        </rollingPolicy>
        <triggeringPolicy class="ch.qos.logback.core.rolling. SizeBasedTriggeringPolicy">
            <maxFileSize>50MB</maxFileSize>
        </triggeringPolicy>
        <encoder>
            <pattern>%date{yyyy-MM-dd} %d{HH:mm:ss. SSS} %-5level %X{traceId} %logger{36} %X{sourceThread} %X{akkaSource} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="FILE" />
    </root>
</configuration>

Este archivo crea la siguiente configuración:

  • El archivo de registro se analiza en busca de cambios en vivo cada minuto (scan="true").

  • La configuración de registro puede ser modificada en vivo con JMX. Más información sobre esto está disponible.http://logback.qos.ch/manual/jmxConfig.html[aquí].

  • Registro de archivos en /opt/ipf/logs/credit-transfer-service.log.

  • Archivos transferidos a /opt/ipf/logs/credit-transfer-service.log.n, donde n es un número entre 1-20, y se reinicia cuando credit-transfer-service.log llega a 50 MB. Tenga en cuenta que solo se conservarán 20 de dichos archivos (es decir, un total de 1 GB de datos de registro).

Este archivo también puede ser extraído por un marco como docs.splunk.com/Documentation/Forwarder/8. 1. 0/Forwarder/Configuretheuniversalforwarder[Splunk forwarder] or Ritmos como se muestra en el diagrama a continuación:

file

System Events

¿Qué son IPF System Events

  • IPF applications están respaldados por un System Event marco, proporcionando capacidades de pub/sub entre los componentes de la aplicación.

  • Jerárquico, extensible, versionado, catalogado. Todas las áreas de aplicación: Técnica, Funcional y Ciclo de Vida. Todo events incluya propiedades comunes: ubicación de origen, hora de creación, nivel, tipo, contexto de asociación, fácil de obtener todo System Events para un pago dado

  • El marco de datos fundamental para capturar el comportamiento de la aplicación, proporcionando un lugar para construir extensible event funcionalidad impulsada, que luego puede ser utilizada en tareas de apoyo como proporcionar datos para la supervisión y la alerta.

  • System Event patrón de suscripción de procesadores: "Actúe sobre todas las advertencias de nivel de infraestructura System Events.

  • Configure múltiples procesadores, estilo funcional, almacenar / transformar – emitir a través de un Conector.

  • Todo el System Events que un IPF Service pueden emitirse, están catalogados y tienen un esquema, están versionados en relación con el software desplegado.

  • Nuevo específico para el cliente events se les anima a ser añadidos para una Solución dada. Proporcionando un entorno muy limpio extension para aprovechar el marco existente y proporcionar información adicional sobre los datos.

events

Dónde están definidos

La lista completa de system events que IPF produce están listados aquí.

Solución de problemas de mensajes de error

El events en este tabla son ERROR events registrado por IPF y describa los pasos de remediación recomendados a seguir si se encuentra con ellos.