Contexto
Un cliente menciona que en opFlow (omk/opFlow/reports) no se pueden generar reportes para fechas anteriores, sólo permite seleccionar la fecha de hoy, como se puede ver en la imagen de abajo:
Incluso cuando se establece una fecha manualmente, el módulo muestra que se está generando el informe:
Pero al hacer clic en "here", aparece el mensaje "Report retrieval failed: No such record exists".
Se han detectado los siguientes errores tanto en la GUI (/omk/opFlow/ops) como en los logs del módulo:
"Report data collection opFlow failed: failed to retrieve summary data: totals aggregation failed: post-count aggregation failed: MongoDB::DatabaseError: exception: operation exceeded time limit" "Report data collection opFlow failed: cannot collect reportdata, database does not hold records for interval... at period precision 3600" "pre-count aggregation failed: MongoDB::DatabaseError: exception: operation exceeded time limit" "hourly CreateSummary failed: pre-count aggregation failed: MongoDB::DatabaseError: exception: operation exceeded time limit"
El archivo mongod.log nos muestra más, esta es la consulta que el código de summary está utilizando, está tomando 63699ms y también nos dice que el tiempo de espera es 60000:
COMMAND [conn5961] command flows.$cmd command: aggregate { aggregate: "conversations", pipeline: [ { $match: { time: { $lte: 1697565600.0, $gte: 1697562000.0 } } }, { $group: { count: { $sum: 1 }, _id: null } } ], allowDiskUse: true, cursor: {}, maxTimeMS: 60000 } keyUpdates:0 writeConflicts:0 numYields:16800 reslen:100 locks:{ Global: { acquireCount: { r: 33606 } }, Database: { acquireCount: { r: 16803 } }, Collection: { acquireCount: { r: 16803 } } } 63699ms
De igual forma, se detecta un aumento en el uso de mongod al ejecutar un top:
En este caso, opFlow procesa flujos cada 2 minutos. Mirando el registro de opFlow nos muestra que cada intervalo está tomando ~ 100 segundos para procesar e insertar en Mongo, la mayor parte de esto se gasta en insertar en Mongo (LoadTime es el tiempo total para obtener los datos, InsertTime es el tiempo de espera para Mongo, FilterTime es el tiempo dedicado a filtrar los datos), como podemos ver a continuación:
[info] worker[22547] STATS Flows=95048 Conversations=86147 LoadTime=101.5 InsertTime=88.0 FilterTime=14.3 Endpoints=3614 EndpointTime=0.0
En este punto, podríamos decir que esto no es un bug ya que el software está funcionando como se espera; el comportamiento es debido a que el servidor tiene poca potencia, esto a su vez está haciendo que parezca que opFlow no está funcionando. Aumentar el valor del tiempo de espera permitirá a opFlow esperar más tiempo a que la consulta termine.
Solución
Cambiar opflow_db_query_timeout ayudará a que el módulo funcione a corto plazo. Si los summary terminan correctamente, los reportes deberían funcionar, si ese es el objetivo (y no utilizar las otras partes de la GUI).
Por tal motivo, se le indica al cliente que debe de aumentar el tiempo de timeout del parámetro opflow_db_query_timeout en el archivo opCommon.nmis.
En un inicio, lo tenía en 65000:
grep -rin "opflow_db_query_timeout" /usr/local/omk/conf/opCommon.nmis 754: 'opflow_db_query_timeout' => 65000,
Se aumenta a 120000 en primera instancia, llegando hasta 300000 que es cuando funciona y los reportes se generan de manera exitosa.
grep -rin "opflow_db_query_timeout" /usr/local/omk/conf/opCommon.nmis 754: 'opflow_db_query_timeout' => 300000,