15/02/2009, 14:14
| ||||
| ||||
| Consulta crear logs Buenas, Tengo una duda, quiero registrar algunos eventos de mi web, por ejemplo: - Cambios de contraseñas - Intentos de cambios contraseñas - Entrada al sitio etc... La pregunta sería si utilizar una tabla de la BBDD para registrarlo o utilizar un TXT. ¿Cuál me aconsejáis? Si optáis por el TXT, me aconsejáis que utilice alguna estructura XML en el fichero, para ser más "reutilizable" o por el contrario sería perder el tiempo? Espero vuestros consejos y experiencia sobre el tema! Muchas gracias  |
|
15/02/2009, 16:30
| ||||
| ||||
| Respuesta: Consulta crear logs @enlinea777: No lo tomes a mal pero, pero, para empezar, las preguntas tontas son aquellas que no se hacen y para continuar, si tu intención es (o era) realmente ayudar, pudiste tratar de ofrecer una respuesta más útil y estructurada. @neodani: La pregunta realmente no es fácil de contestar sin tomar en cuenta varios factores: 1. La carga que puede generar el guardar los eventos que te interesan. 2. Lo que usarías para mantener "limpio" el recurso que utilices para guardar la información (Hay que limpiar o crecerá y crecerá sin límites más allá de los que pueda ofrecer el medio de almacenamiento, lo que afectaría a otras cosas que también necesitan guardarse) 3. La seguridad 4. Lo que tienes pensado para la presentación de la información guardada 5. La complejida que, para tí, implica cualquiera de las soluciones disponibles. Voy por cada punto: 1. De guardar en la base de datos, el uso de consultas poco óptimas podría generar una carga importante en el servidor de la base de datos dependiendo de la cantidad de eventos que desees guardar y del modo de utilizar las consultas, por ende, una cosa importante sería guardar los eventos que son realmente necesarios guardar y buscar información sobre qué tipo de consulta puede ser la más eficiente en base al servidor de base de datos que utilices. Si guardas en archivos de texto (sea .txt, .xml, o cualquier similar) no hay carga en el servidor de la base de datos por lo que difícilmente podrías ver el funcionamiento del sitio afectado a la hora de guardar los diferentes eventos. La única carga acá tal vez a considerar sería el I/O generado a nivel del dispositivo de almacenamiento, cosa que es poco probable que afecte incluso en el más pobre de los servicios de hosting. 2. Ambas soluciones (en la base de datos o en un archivo de texto) deben estar acompañadas de alguna función que se encargue de descartar eventos almacenados que ya no son útiles (por que son viejos o lo que sea), en archivos de texto sin embargo será menor el espacio a consumirse por cada evento guardado, no obstante, es importante ofrecer para ambos una herramienta que evite que el número de eventos guardados crezca sin detenerse. 3. Los archivos de texto, a menos que configures opciones en el servidor http, permisos de acceso o los guardes fuera del root donde está la parte pública del sitio, podrían ser visibles desde un navegador cualquiera si se llega a conocer el nombre del archivo que guarda tal información, ya sea porque alguien decidió usar un spider o por algún enlace publicado de fácil acceso que indica la ubicación de estos archivos, cosa que implica un riesgo de seguridad a menos que la información de los eventos guardados no sea muy relevante o no te interese si cualquiera los ve. En la base de datos este posible problema de seguridad decrese enormemente ya que para tener acceso a la información guardad en relación a los eventos, se dependerá de la información de acceso al servidor de la base de datos lo que, a menos que estén muy mal protegidos, evitará que alguien que no deba, tenga acceso a la información. 4 y 5. Tú conocerás tus virtudes y limitaciones en lo que a códigos se refiere y nadie mejor que tú para saber si para tí sería más fácil guardar y extraer los datos de una base de datos desde lo que sea utilice el sitio para comunicarse con dicha base de datos, o la facilidad que puedas tener para leer todo desde archivos de texto, para los últimos, podría ser tan simple como abrirlos en el navegador directamente o podrías usar código que se encargue de maquetarlos antes de presentarlos y no ver todo en crudo. Es importante que tomes en cuenta tus limitaciones para que evites crear algo eficaz.
__________________ Usuario Reigistrado de linux #399288 |
|
15/02/2009, 17:18
| ||||
| ||||
| Respuesta: Consulta crear logs Cita: Muchas gracias Acron_0248 por tu respuesta!
Iniciado por Acron_0248  @enlinea777: No lo tomes a mal pero, pero, para empezar, las preguntas tontas son aquellas que no se hacen y para continuar, si tu intención es (o era) realmente ayudar, pudiste tratar de ofrecer una respuesta más útil y estructurada. @neodani: La pregunta realmente no es fácil de contestar sin tomar en cuenta varios factores: 1. La carga que puede generar el guardar los eventos que te interesan. 2. Lo que usarías para mantener "limpio" el recurso que utilices para guardar la información (Hay que limpiar o crecerá y crecerá sin límites más allá de los que pueda ofrecer el medio de almacenamiento, lo que afectaría a otras cosas que también necesitan guardarse) 3. La seguridad 4. Lo que tienes pensado para la presentación de la información guardada 5. La complejida que, para tí, implica cualquiera de las soluciones disponibles. Voy por cada punto: 1. De guardar en la base de datos, el uso de consultas poco óptimas podría generar una carga importante en el servidor de la base de datos dependiendo de la cantidad de eventos que desees guardar y del modo de utilizar las consultas, por ende, una cosa importante sería guardar los eventos que son realmente necesarios guardar y buscar información sobre qué tipo de consulta puede ser la más eficiente en base al servidor de base de datos que utilices. Si guardas en archivos de texto (sea .txt, .xml, o cualquier similar) no hay carga en el servidor de la base de datos por lo que difícilmente podrías ver el funcionamiento del sitio afectado a la hora de guardar los diferentes eventos. La única carga acá tal vez a considerar sería el I/O generado a nivel del dispositivo de almacenamiento, cosa que es poco probable que afecte incluso en el más pobre de los servicios de hosting. 2. Ambas soluciones (en la base de datos o en un archivo de texto) deben estar acompañadas de alguna función que se encargue de descartar eventos almacenados que ya no son útiles (por que son viejos o lo que sea), en archivos de texto sin embargo será menor el espacio a consumirse por cada evento guardado, no obstante, es importante ofrecer para ambos una herramienta que evite que el número de eventos guardados crezca sin detenerse. 3. Los archivos de texto, a menos que configures opciones en el servidor http, permisos de acceso o los guardes fuera del root donde está la parte pública del sitio, podrían ser visibles desde un navegador cualquiera si se llega a conocer el nombre del archivo que guarda tal información, ya sea porque alguien decidió usar un spider o por algún enlace publicado de fácil acceso que indica la ubicación de estos archivos, cosa que implica un riesgo de seguridad a menos que la información de los eventos guardados no sea muy relevante o no te interese si cualquiera los ve. En la base de datos este posible problema de seguridad decrese enormemente ya que para tener acceso a la información guardad en relación a los eventos, se dependerá de la información de acceso al servidor de la base de datos lo que, a menos que estén muy mal protegidos, evitará que alguien que no deba, tenga acceso a la información. 4 y 5. Tú conocerás tus virtudes y limitaciones en lo que a códigos se refiere y nadie mejor que tú para saber si para tí sería más fácil guardar y extraer los datos de una base de datos desde lo que sea utilice el sitio para comunicarse con dicha base de datos, o la facilidad que puedas tener para leer todo desde archivos de texto, para los últimos, podría ser tan simple como abrirlos en el navegador directamente o podrías usar código que se encargue de maquetarlos antes de presentarlos y no ver todo en crudo. Es importante que tomes en cuenta tus limitaciones para que evites crear algo eficaz. Te respondo a ella 1) Ahí no lo se con exactitud, igual hablamos de 1.000 - 2.000 lineas diarias aprox. 2) Ya había pensado que como todos los logs crecen y crecen. En cualquier caso, el mantenimiento lo llevaría desde la parte del servidor, con algun script que vaya "rotando" el log cada cierto tamaño y eliminando cada cierto tiempo. 3) Me llama bastante más la idea de utilizar un TXT como bien dices fuera de la raiz del sitio público. 4) Para presentar los datos (no al publico sino a mi, ya sea en un panel de administración) sería cuestión de leer los datos del fichero. 5) Aquí es donde se presenta la mayor duda, llamadme exceptico o como queráis, pero se puede dar el caso que el fichero este abierto escribiendo una linea, cuando otro usuario produce un evento distinto? En ese caso que hace el fichero abierto? se cierra y se escribe la nueva petición? se machacan los datos? Existe alguna forma de evitar que se machaquen los datos? ya sea utilizando algun if del palo... si esta abierto espera x segundos y vuelve a intentarlo, no lo sé..... existe algo que evite tener que hacer eso? Muchas gracias |
|
15/02/2009, 17:38
| ||||
| ||||
| Respuesta: Consulta crear logs 1) Sería cosa de probar y ver la carga que se genere. 2) Osea, lo manejarás mediante un cron a nivel del servidor lo que cual parece perfecto. 3) Es útil, sip, prueba sin embargo qué tan difícil se te podría hacer tomando en cuenta permisos de archivos a nivel del servidor. 4) Se entiende, la cuestión es lo que tengas en mente sobre cómo llevar a cabo ese proceso. 5) De poder darse el caso, se puede, realmente dependendería por un lado de cosa de suerte, pero por otro, la probabilidad de que varios eventos puedan generarse de forma paralela y esto dependerá a su vez del evento. Por ejemplo, si almacenas la llegada de un usuario y también los cambios de contraseñas, es poco probable que ambos lleguen a escribirse simultáneamente porque los cambios de contraseña no serán tan regulares como la llegada de un usuario al sitio; ahora, si guardas la llegada y la salida del usuario al sitio, la probabilidad de que ambos eventos se quieran guardar a la vez, aumenta. Dependiendo de la implementación, puede ser problemático o no, por ejemplo, si usas fopen y relacionadas, para escribir un evento primero debes abrir el archivo como lectura/escritura, guardar el evento y cerrar; en este caso, debería haber una comprobación en la función que se encarga de guardar los eventos que verifique si el archivo ya está abierto y listo para la escritura y en ese caso, pasar directamente a guardar el evento. Sinceramente no puedo dar mayores detalles, depende mucho de cómo manejarás el almacenamiento de los eventos, si guardas en la base de datos sin embargo, esta no sería una preocupación
__________________ Usuario Reigistrado de linux #399288 |
