Registro exhaustivo para supervisión y análisis
Active el registro de buckets y consulte los registros de todas las solicitudes realizadas a los buckets. Los registros de acceso contienen registros detallados de las solicitudes, como la dirección IP del solicitante, la hora de la solicitud, la identidad del solicitante, el tipo de solicitud (por ejemplo, PUT, GET) y el tamaño de los datos devueltos.
Puede activar el registro de cubos a través de la consola web de IDrive® e2 o utilizar el cliente API. Estos registros pueden utilizarse para auditoría y análisis, especialmente para seguridad, control de acceso y supervisión de uso.
Casos prácticos de Bucket Logging
- Auditoría de seguridad: Identificar intentos o patrones de acceso no autorizados.
- Control de acceso: Rastrea quién accede a tus datos y qué acciones realiza.
- Supervisión del uso: Supervisa las estadísticas de uso para una mejor gestión de los costes.
- Solución de problemas: Ayuda a diagnosticar errores relacionados con permisos de acceso o errores de aplicación.
Comprender la estructura del registro de cubos
Cada entrada de registro incluye los siguientes campos:
- 1. ID del propietario del cub o : ID de la cuenta propietaria del cubo.
- 2. Bucket Name: El nombre del bucket e2 que ha recibido la solicitud.
- 3. Hora: Hora a la que el servidor e2 recibió la solicitud. Sigue el formato [dd/Mon/aaaa:hh:mm:ss ±zzzz].
- 4. Dirección IP remota: La dirección IP del solicitante (el cliente que envió la solicitud).
- 5. Solicitante: El ID de la cuenta o usuario IAM que realizó la solicitud. Para e2 aparecerá como -.
- 6. ID de la solicitud: Identificador único de la solicitud.
- 7. Operación: Tipo de operación realizada (por ejemplo, GET, PUT, POST, DELETE, LIST).
- 8. Clave: La clave (o ruta) del objeto implicado en la solicitud.
- 9. Request-URI: El URI de la solicitud, que incluye la ruta del objeto solicitado y la cadena de consulta si está presente.
- 10. Código de estado HTTP: El código de estado HTTP devuelto por el servidor S3 al cliente.
- 11. Código de error: El código de error (si existe) asociado a la solicitud. Si no hay ningún error, este campo es -.
- 12. Bytes enviados: El número de bytes enviados al cliente en respuesta a la solicitud. Esto incluye el tamaño del objeto devuelto, así como cualquier dato adicional.
- 13. Tamaño del objeto : Tamaño del objeto solicitado. Sólo se incluye para las peticiones GET y HEAD.
- 14. Tiempo total: El número de milisegundos que la petición estuvo en vuelo desde la perspectiva del servidor. Este valor se mide desde el momento en que se recibe la solicitud hasta el momento en que se envía el último byte de la respuesta.
- 15. Tiempo de respuesta: El número de milisegundos que el servidor tardó en procesar su solicitud. Este valor se mide desde el momento en que se recibió el último byte de la petición hasta el momento en que se envió el primer byte de la respuesta.
- 16. Remitente: La URL de referencia (si existe).
- 17. User-Agent: La cadena de agente de usuario enviada por el cliente que realiza la solicitud. Puede proporcionar información sobre el navegador o el programa del cliente.
- 18. ID de versión: Si el objeto está versionado, este campo contendrá el ID de versión del objeto al que se ha accedido. Si el versionado no está habilitado, este campo será -.
- 19. Host Id : El DNS del punto final e2.
- 20. Versión de firma : La versión de firma, SigV2 o SigV4, que se utilizó para autenticar la solicitud o un - para solicitudes no autenticadas.
- 21. Cipher Suit: El cifrado Secure Sockets Layer (SSL) que se negoció para una solicitud HTTPS o un - para HTTP. Para e2, se establece como -.
- 22. Tipo de autenticación: El tipo de autenticación de solicitud utilizado: AuthHeader para cabeceras de autenticación, QueryString para cadena de consulta (URL prefijada), o un - para peticiones no autenticadas.
- 23. Host Header: El punto final utilizado para conectarse a e2.
- 24. Versión TLS: Se establece como "-" para e2.
- 25. Punto de acceso ARN: Sería "-" para e2.
- 26. aclRequired: Se registraría como "-" para e2.
Nota: Mantener los registros en el bucket de destino indefinidamente puede incurrir en costes adicionales, ya que los registros se contabilizan en el uso total de datos.