Hay que tener en cuenta algunos elementos de alto impacto en la solución que se plantee:

1. Debemos registrar los logs generados por la solución entregada.
2. Asumamos la solución entregada debería estar como máximo entre un 70 y 80% de su capacidad en los picos de carga con el objeto de tener margen de crecimiento.
3. Los logs deberían conservarse al menos 7 días (no tendría sentido periodos inferiores ya que podemos perder información muy importante). Nos podemos hacer una idea bastante clara de la cantidad de Gb de información que supone esto.

Ahora vamos a aquellas cosas que NO podemos hacer por poner en riesgo la estabilidad del sistema:

• Registrar los logs en los en el sistema se archivos de la solución entregada. Si observamos el punto 3 nos quedaremos rápidamente sin sitio y tumbaremos el sistema; eso está descartado, se considera mala praxis en contenedores.
• Registrar los logs en la BBDD de la solución entregada. De nuevo el punto 3 aparece como una condena ¿cuanto tardaremos que dejar sin espacio al namespace de la BBDD?
• La solución entregada registra la información en un volumen persistente. Esto implica que que una herramienta que está al 70-80% de su capacidad debe administrar también los logs y los ficheros asociados.

Estos puntos descartan el uso de los recursos de la solución entregada para la tarea de gestión de logs. Dicho de otra forma, tenemos entonces estas restricciones:

• La información debe salir de los pods
• Cuanta mas carga de trabajo en la solución entregada mas logs se generan y si los administra la propia solución entregada mas carga que debe asumir, por lo que no debe realizar esa tarea
• En el caso de una solución ya finalizada o un producto el control sobre el código y por lo tanto de la instrumentación es limitado.

Teniendo claro que debemos sacar la información de la solución entregada mediante otro aplicativo tenemos las siguientes cuestiones:

1. ¿Qué aplicativo usamos?
2. ¿Dónde registramos la información generada?

Para el punto 1 tenemos las siguientes opciones como alternativas viables:

• OpenTelemetry:
  • La aplicación ya existe: Otel- javaagent
  • Es estable.
  • Forma de trabajar:
    • Tiene que enviar la información a un Collector de OpenTelemetry.
    • El collector es un pod externo a la solución entregada y no impactará en su rendimiento
    • Desde el Collector se puede exportar a donde se desee ya que posee numerosos exportadores ya desarrollados.
  • Consecuencia:
    • Nos acerca al objetivo final por lo que aprovechamos todo lo que se haga
• kafka producer:
  • La aplicación no existe
  • La aplicación debería leer de la consola los logs y enviarlos a un Topic kafka.
  • Forma de trabajar:
    • El nuevo desarrollo básicamente debe funcionar como Opentelemetry ya que no queremos ni mas carga ni bloqueos por la gestión de ficheros, es decir como un aplicativo ejecutándose en el mismo pod que la solución y leyendo de la consola.
    • La información leída se debe mandar a kafka con una garantía de at-least-once y debemos tener un kafka con un topic optimizado para asumir la carga de trabajo (particiones/replicas/ políticas de retención etc).
  • Consecuencias:
    • Hablamos de un nuevo desarrollo que es complejo.
    • Igualmente necesitamos de una infraestructura para dar soporte, en este caso kafka
    • Todo lo que hagamos se va a desechar en cuanto se levante la observabilidad con opentelemetry
    • En cuanto tengamos la  observabilidad de CTI deberemos implementar igualmente la opción  1.- Opentelemetry

Estas dos alternativas envían la información a un elemento de infraestructura mediante un protocolo optimizado (habitualmente grpc) lo que nos daría el rendimiento que buscamos

Evaluemos ahora qué hacer con la información registrada:

• Collector OpenTelemetry
  • Ya dispone de exportadores: esto significa que podemos elegir qué hacer, desde enviarla a consola, a un fichero, enviarla otro collector, un elastic, kafka... . Tenemos una amplia variedad de exportadores que ya están disponibles.
• Kafka
  • Es necesario crear consumidores para poder sacar la información
  • También podemos optar por dejar la información en kafka para lo cual es necesario aprovisionar espacio suficiente en Kafka para asumir la información de logs que va a llegar
  • Si dejamos la información en kafka hay que asumir el problema de consultarla, lo que de nuevo nos lleva a la necesidad de un consumidor a desarrollar