Solución de registro de nivel empresarial

Estamos buscando una solución de registro de nivel empresarial que tenga algunas de las características de registro en una base de datos y archivos de registro regulares.

1) Solo los desarrolladores pueden leer los archivos de registro regulares. Los clientes también quieren acceder a algunos registros. Como eventos de una compra que hicieron.

2) Los archivos de registro normales no se pueden consultar. No necesitamos consultas complejas, uniones, etc., pero deseamos encontrar registros sobre un elemento en particular en el sistema entre dos fechas y ese tipo de cosas.

3) Las bases de datos no son "almacenables", como si no pudiera simplemente mover registros antiguos a mi máquina sin perturbar el sistema en ejecución real.

4) Las bases de datos requieren mantenimiento. El mantenimiento de la propia base de datos de la aplicación es una carga de trabajo y no quiero agregarle el mantenimiento de una segunda base de datos. Los archivos de registro aún se pueden leer después de un bloqueo grave del sistema, etc., y no requieren mucho mantenimiento.

5) Para ambos: los registros comerciales son importantes, no son como las estadísticas de acceso a sitios web donde perder algo no importa.

Más o menos así. ¿No hay una solución que tenga un poco de lo mejor de ambos mundos?

Qué sistema operativo sería relevante, Windows ofrecería soluciones bastante diferentes de algo basado en Linux.
Las máquinas de desarrollo son Windows y la aplicación real se ejecuta en CentOS.

Respuestas (1)

Bueno, intentémoslo en caso de que nadie más con un mejor conocimiento entre. Por lo tanto, no es realmente una respuesta, sino más bien una indicación de algunas opciones que pueden ayudarlo.

Primero, sería interesante qué cantidad de 'registros' espera. El punto uno (eventos de compra) parece no ser muy grande. También sobre el punto 3, siempre puede volcar algo de SQL en un archivo que no debería perturbar mucho el sistema.

Parece que lo que quieres estaría en la línea de una base de datos NoSQL. (Aunque dice que no desea ninguna carga de trabajo de mantenimiento de base de datos adicional). Pero algunos tipos de almacenes de valor clave (p. ej., Redis) serían muy fáciles de usar y otros serían lo suficientemente fáciles y ofrecerían exactamente el tipo de búsqueda que desea realizar.

Como está escrito en mi comentario en Programmers.SE, la pila ELK podría ser una forma de hacerlo. Elasticsearch para búsqueda (con Kibana como una interfaz lo suficientemente cómoda) y Logstash como uno de los estándares de la industria para registros (con Redis para almacenamiento como una opción). Aunque esto está destinado a registros de gran volumen como registros de Apache, registros de sb y registros basados ​​en sistemas similares.

Podrías usar esto fácilmente como un punto de partida. Si no tiene un volumen muy alto, aún puede usar Elasticsearch junto con Kibana y agregar alguna API al frente para la autenticación.

Quizá también intentemos repasar todos los puntos uno por uno:

1) La mayoría de los sistemas de este tipo (también la mayoría de las bases de datos NoSQL) no ofrecen mucho en la línea de autenticación de usuarios. Entonces, su única opción en este caso sería escribir una interfaz para los usuarios que maneje esto. (Digamos que los desarrolladores usarían Kibana con acceso completo y la interfaz aún podría ejecutar consultas con la sintaxis bastante simple de Elasticsearch)

2) Exactamente lo que ofrece ELK (y otras soluciones NoSQL).

3) A menos que esté hablando de volúmenes de datos muy altos, eso simplemente no es cierto.

4) Bueno, o desea una consulta fácil o un almacenamiento simple como archivos. Si instala un 'sistema', tendrá que mantenerlo hasta cierto punto. No sabría de nada que maneje datos, garantice persistencia y no requiera mantenimiento.

5) La mayoría de las soluciones NoSQL permiten hacer lo que quieras. Cuál es exactamente el mejor dependería, pero Elasticsearch o MongoDB permitirían configurarse con 100% de persistencia. Las compensaciones que se deben realizar (como en el teorema de 2 de 3 CAP solo son relevantes con volúmenes de datos súper altos en muchos grupos).

Tal vez eche un vistazo al sitio de Elasticsearch, tienen algunos tutoriales en video que demuestran ELK y no le costará más de una hora de su tiempo verlos. Al menos, le dará algunas ideas interesantes sobre lo que es posible allí.