Visión general
La gestión del registro de eventos es un aspecto crucial para mantener la seguridad y la responsabilidad en los sistemas de control de acceso. Esta guía explorará cómo administrar de manera efectiva los registros de eventos en dispositivos Suprema utilizando tanto el SDK de dispositivos BioStar 2 como el G-SDK de Suprema.
1. Descripción general del registro de eventos
Los códigos de evento del SDK se definen de la siguiente manera. Consulte el enlace a continuación para obtener más detalles.
https://github.com/supremainc/BioStar2_device_SDK/blob/master/Example_Cpp/Include/BSCommon/data/BS2Event.h
(El archivo event_code.json se incluye en el código de ejemplo del G-SDK).
Si necesita información detallada sobre los registros, consulte los sitios web oficiales de cada uno.
SDK del dispositivo: https://kb.supremainc.com/bs2sdk/doku.php?id=en:log_management_api
Suprema G-SDK: https://supremainc.github.io/g-sdk/api/event/
2. Administración de registros de eventos con el SDK de dispositivos BioStar 2
Parte 1. Llamada a la API
BioStar 2 Device SDK y Suprema G-SDK proporcionan una interfaz de alto nivel para administrar registros de eventos en múltiples dispositivos desde un servidor centralizado.
[Recuperación de registros de eventos]
Hay dos formas principales de recibir registros del dispositivo mediante el SDK:
- Solicitud de registros del dispositivo.
SDK del dispositivo: https://kb.supremainc.com/bs2sdk/doku.php?id=en:bs2_getlog
Suprema G-SDK: https://supremainc.github.io/g-sdk/api/event/#getlog
- Recepción de registros de monitoreo en tiempo real.
SDK del dispositivo:https://kb.supremainc.com/bs2sdk/doku.php?id=en:bs2_startmonitoringlog
Suprema G-SDK:https://supremainc.github.io/g-sdk/api/event/#enablemonitoring
- Solicitud de registros filtrados del dispositivo. [Obsoleto] Artículo: ¿Por qué quedaron en desuso los registros filtrados? (Plan Futuro)
[Eliminación de registros de eventos]
Se eliminarán todos los registros del dispositivo. No hay una API para eliminar registros parcialmente.
SDK del dispositivo: https://kb.supremainc.com/bs2sdk/doku.php?id=en:bs2_clearlog
Suprema G-SDK: https://supremainc.github.io/g-sdk/api/event/#clearlog
Parte 2. Estructura del registro de eventos
En esta parte, explique la estructura común de los registros de eventos.
1. Identificación
ID de registro que aumenta automáticamente de 1 cuando se genera el registro.
- Si conoce el primer y el último registro, puede saber cuántos registros se almacenan en el dispositivo.
[Verifique los registros iniciales almacenados en el dispositivo mediante el SDK del dispositivo]
Como se puede ver en la foto, se han eliminado los registros anteriores a 2437.
No hay ninguna API para obtener el último índice de registro (ID).
2. dateTime (formato de hora Unix)
La hora a la que se ha generado el registro. Significa los segundos que pasan desde UTC hasta la hora actual.
3. ID de dispositivo
ID del dispositivo que generó el registro.
4. Código de evento
El código de evento consta de un código principal y un código secundario.
El resto de datos varían en función del tipo de evento. Consulte la documentación del SDK para obtener más detalles.
3. Consejos para administrar registros de eventos
Las funciones para recuperar registros a través de filtros han quedado obsoletas.
(De BioStar 2 Device SDK 2.9.6 y Suprema G-SDK 1.7.0).
La API GetLogWithFilter de filtrado de registros del dispositivo revisa los registros del dispositivo con las condiciones establecidas por el servidor.
Esto significa que el dispositivo puede invertir un tiempo considerable en el filtrado de registros y, a medida que aumente el número de registros en el dispositivo, se necesitará más tiempo.
Además, los registros no se almacenan permanentemente en el dispositivo.
Si se supera el número máximo de registros que el dispositivo puede contener, el dispositivo sobrescribirá los registros más antiguos y los registros anteriores a un determinado período de tiempo se pueden eliminar automáticamente.
Se recomienda que todos los registros del dispositivo se almacenen y administren en un servidor.
Se recomienda que los registros se reciban de forma masiva desde el dispositivo mediante la API GetLog y que los registros que se produzcan después de la hora actual se reciban en tiempo real mediante las API EnableMonitoring y SubscribeRealtimeLog, de modo que el servidor almacene todos los registros en un DBMS adecuado y filtre los registros del DBMS.