Preguntas más frecuentes del protocolo de la API REST de rastreo de mensajes de Office 365

¿Qué permisos son necesarios para recopilar registros de la API REST de rastreo de mensajes de Office 365?

Utilice los permisos de aplicación concedidos a su entidad de servicio en Microsoft Entra ID para acceder a los datos de seguimiento de mensajes en Exchange Online. Para obtener más información, consulte: Permisos de la API de seguimiento de mensajes ( https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/graph-api-message-trace#permissions-required ).

¿Qué información está contenida en los sucesos recopilados por un protocolo de API REST de rastreo de mensajes de Microsoft Office 365 ?

El protocolo de la API REST de seguimiento de mensajes de Microsoft devuelve la información de seguimiento de un mensaje de correo electrónico a medida que este transita por la organización de Exchange Online. El seguimiento de mensajes permite a los administradores de inquilinos realizar un seguimiento del ciclo de vida de un correo electrónico, determinar su estado de entrega (ya sea entregado, pendiente, fallido o en cuarentena) y conocer las acciones que se han aplicado al mismo. Para cada mensaje, devuelve campos como el remitente, el destinatario, el asunto, la fecha y la hora de recepción, el estado y los eventos de seguimiento asociados al mensaje

Para obtener una lista completa de los campos disponibles, consulte el recurso «Message Trace» ( https://learn.microsoft.com/en-us/graph/api/resources/exchangemessagetrace?view=graph-rest-1.0 ).

¿Para qué se utiliza la opción de retardo de sucesos?

La opción de retardo de sucesos se utiliza para evitar que se pierdan sucesos. Los sucesos perdidos, en este contexto, se producen porque pasan a estar disponibles después de que el protocolo haya actualizado su rango de consulta a un intervalo de tiempo más reciente que la hora de llegada del suceso. Si se produjo un evento pero no se publicó en la API REST de seguimiento de mensajes de Microsoft, cuando el protocolo consulta la hora de creación de ese evento, no lo encuentra.

Ejemplo 1: el ejemplo siguiente muestra cómo se puede perder un suceso.

El protocolo consulta la API de seguimiento de mensajes de Microsoft a las 14:00 para recopilar los eventos ocurridos entre las 13:00 y las 13:59. La respuesta de la API de rastreo de mensajes de Microsoft muestra los eventos disponibles en dicha API entre las 13:00 y las 13:59. El protocolo funciona como si se recopilaran todos los eventos y, a continuación, envía la siguiente consulta a la API de rastreo de mensajes de Microsoft a las 15:00 para obtener los eventos que tuvieron lugar entre las 13:45 y las 14:59. El problema de este escenario es que es posible que la API de seguimiento de mensajes de Microsoft no incluya todos los eventos que tuvieron lugar entre las 13:00 y las 13:59. Si un evento se produjo a las 13:58, es posible que no esté disponible en la API de seguimiento de mensajes de Microsoft hasta las 14:03. Sin embargo, el protocolo ya ha consultado el rango de tiempo de la 1:00 PM a la 1:59 PM y no puede volver a consultar ese rango sin obtener sucesos duplicados. Este retardo puede variar entre 1 minuto y 24 horas.

Ejemplo 2: El ejemplo siguiente muestra el Ejemplo 1, excepto en este caso de ejemplo, se añade un retardo de 15 minutos.

Este ejemplo utiliza un retardo de 15 minutos cuando el protocolo realiza llamadas de consulta. Cuando el protocolo realiza una llamada de consulta a la API de seguimiento de mensajes de Microsoft a las 14:00, recopila los eventos que tuvieron lugar entre las 13:00 y las 13:45. El protocolo funciona como si se hubieran recopilado todos los eventos, envía la siguiente consulta a la API de rastreo de mensajes de Microsoft a las 15:00 y recopila todos los eventos que se produjeron entre las 13:45 y las 14:45. En lugar de que se pierda el suceso, como en el Ejemplo 1, se recoge en la siguiente llamada de consulta entre las 1:45 PM y las 2:45 PM.

Ejemplo 3: El ejemplo siguiente muestra el Ejemplo 2, excepto en este escenario, los sucesos están disponibles un día después.

Si el evento se produjo a las 13:58, pero no estuvo disponible para la API de seguimiento de mensajes de Microsoft hasta las 13:57 del día siguiente, el retraso del evento descrito en el ejemplo 2 ya no tendrá en cuenta ese evento. En su lugar, el retardo del suceso debe establecerse en un valor más alto, en este caso 24 horas.

¿Cómo funciona la opción de retardo de suceso?

En lugar de consultar de la hora del último suceso recibido a la hora actual, el protocolo consulta de la hora del último suceso recibido a la hora actual -<retardo de suceso>. El retardo del suceso es en segundos. Por ejemplo, un retardo de 15 minutos (900 segundos) significa que sólo consulta hasta hace 15 minutos. Esta consulta concede a la API de rastreo de mensajes de Microsoft un plazo de 15 minutos para que un evento esté disponible antes de que se pierda. Cuando la diferencia entre la hora actual y el <retardo del evento> es menor que la hora del último evento recibido, el protocolo no consulta la API de seguimiento de mensajes de Microsoft; espera a que la condición desaparezca antes de realizar la consulta.

¿Qué valor utilizo para la opción de retardo de evento?

La API de rastreo de mensajes de Microsoft puede retrasar la disponibilidad del evento hasta 24 horas. Para evitar que se pierdan sucesos, el valor de la opción de parámetro Retardo de sucesos se puede establecer en 24 horas. Sin embargo, cuanto mayor sea el retardo del evento, menos tiempo real serán los resultados. Con un retardo de sucesos de 24 horas, sólo verá los sucesos 24 horas después de que se produzcan. El valor depende del riesgo que esté dispuesto a asumir y de la importancia de los datos en tiempo real. Este retardo predeterminado de 15 minutos proporciona un valor que se establece en tiempo real y también impide que se pierdan la mayoría de los sucesos.

Para obtener más información sobre la función de seguimiento de mensajes, incluidas las preguntas frecuentes de los usuarios, los casos de resolución de problemas y el comportamiento de los datos, consulte las preguntas frecuentes sobre el seguimiento de mensajes de Microsoft ( https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-FAQ ).