[NC-52120] Daily report - Reports are received every day at different time - bug

I remember that I posted this issue in v16 and even in v17 and the answer was: "the daily report is processed in a way to have the least impact on the XG so reports are processed every day depending on the resource load".

I am the only one since v16 with this issue? I tried both internal smtp and external smtp, but no changes. Now external smtp is used.

Thanks




[locked by: Stuart Hatto at 11:31 AM (GMT -7) on 15 Oct 2019]
[unlocked by: Stuart Hatto at 6:28 AM (GMT -7) on 16 Oct 2019]
Parents Reply Children
  • Luk, I have kicked off an investigation, but going back to your original screenshot it shows reports being delivered to a mailbox at 1-2 hrs after the 'send at' time. Could it be external delivery delays that are also additive??

     

  • I do not think so, as failed logins, appliance restart, backup configuration are not delayed at all.

    I tried with local XG smtp settings. Same thing!

  • Hi Luk,

    Circling back to this issue.

    This is an example of terminological inexactitude :) In other words "Send e-Mail at" doesn't mean what you (we) think it means.

    The report scheduling system looks for reports being scheduled every hour and if it finds a report has been scheduled it starts to produce that report. The report can take variable amounts of time depending upon amount of data, system load, other resource constraints like CPU and memory.

     

    So "Send e-Mail at" actually means "Begin producing report at"

     

    I am going to work with engineering to understand how we can best resolve this UI language issue - I doubt we will resolve this before GA as I don't think its as easy as simply changing the words. Unless you think a change of wording and documentation would suffice?

    I know this has been something you've reported for a while now, so thank you for your patience, we will resolve the confusion. However, as it stands the reports will still be received at variable times depending on the circumstances above, so my best advice at this time is if you want to see a report at a specific time, schedule it 2 hours earlier than you need it.

  • Unknown said:

    I am going to work with engineering to understand how we can best resolve this UI language issue - I doubt we will resolve this before GA as I don't think its as easy as simply changing the words. Unless you think a change of wording and documentation would suffice?

    I know this has been something you've reported for a while now, so thank you for your patience, we will resolve the confusion. However, as it stands the reports will still be received at variable times depending on the circumstances above, so my best advice at this time is if you want to see a report at a specific time, schedule it 2 hours earlier than you need it.

     this is an example of XG bad design. I think that you should investigate to re-engineer the process and make sure we receive the report at scheduled time and changing the work is not a nice workaround. Time is time. So, all the time, we need to explain to customers: "yes, it is by design. As you can read, the report starts to be calculated at that time and you will receive the report each day at different time." This is already being explained to them.

    Now: think about how to fix the issue properly (no workaround) but as I showed, the report is from the day before, so you can:

    • really generate the report at the time of the scheduled time and send it within 1/3 minutes OR
    • generate the report at midnight and save it somewhere in the /var/log or /var/reports and send it at the scheduled time

    Up to you. In my case, I am receiving reports even after more than 1 hour, there are more than something that you need to re-engineer as I have 3/5 IPs at home and few rules. If extracting logs from the DB requires so much time...I am sure you need to go back to design phase and understand how to built a new reporting module. This is not a bad idea, as logging and reporting (at the moment) are the worst topic on XG.

    With UTM 9 SG650 with 4000 users, daily report arrives within 3 minutes. Just to let you know some differences.

    Thanks

  • I have to agree with Luk. There is something seriously wrong with the database if it can't generate simple reports within a few minutes. A correctly sized system shouldn't be so overwhelmed that it can't generate a report promptly. If there is a cron job that starts a report every hour on the scheduled time, maybe you guys can change the cron timing and start the report 15-20 minutes before the gui calls for it for daily reports and then queue it for mail at the scheduled time. Just throwing ideas here since a KB article saying a 9am report doesn't mean 9am, it could be 9 or 10 or whatever depending on system load is not something an end user wants to hear.

    Thanks for your efforts on this by the way.

  • To be honest, I prefer that they fix the problem at source. As you said, if XG cannot generate reports in few minutes, something must be revisited or built from scratch.

  • I was going to post about central reporting but alas; they just need to fix it on box.

    Something so simple yet nobody seems to see the point of a scheduled report?  If it's this big of an issue, maybe rip out on-box reports all together and use that space/horsepower for log archives, verbose logging, etc.  Force everyone to central for advanced metrics and reporting.  I know this isn't a solution...just my frustrated opinion.

  • Hello Stuart Hatto,

    I apologize, but I will repeat again: could your developers use what do you have at home?

    I mean reporting module in UTM v9. In the past, this system (I guess sometimes v8.3 or v8.4) also had problems with fast enough report generation, and the developers solved this problem quite neatly - and this system is still in use for report generation in v9!

    The principle is trivially simple, at regular intervals cron deamon assigns a reporting module to continuously pre-process report data in small portions during the day so that when the report is to be processed for the whole period (day or week) the system is not extremely busy and generate reports in the required time. That shouldn't be a problem to apply in v18 EAP1?!?

    And again my advice is free ....

    Regards

    alda

  • Unknown said:

    Hi Luk,

    Circling back to this issue.

    This is an example of terminological inexactitude :) In other words "Send e-Mail at" doesn't mean what you (we) think it means.

    The report scheduling system looks for reports being scheduled every hour and if it finds a report has been scheduled it starts to produce that report. The report can take variable amounts of time depending upon amount of data, system load, other resource constraints like CPU and memory.

     

    So "Send e-Mail at" actually means "Begin producing report at"

     

    I am going to work with engineering to understand how we can best resolve this UI language issue - I doubt we will resolve this before GA as I don't think its as easy as simply changing the words. Unless you think a change of wording and documentation would suffice?

    I know this has been something you've reported for a while now, so thank you for your patience, we will resolve the confusion. However, as it stands the reports will still be received at variable times depending on the circumstances above, so my best advice at this time is if you want to see a report at a specific time, schedule it 2 hours earlier than you need it.

     

    With all due respect, I think this is an example of you guys tying yourselves in knots trying to convince everyone that what looks like a duck, swims like a duck, and quacks like a duck, is in fact, not a duck.  The simple fact is that I personally have several applications (and I suspect the other users on this forum could point out their own) that run scheduled reports and the reports always generate and run when scheduled.  If its taking hour(s) to generate a report, something is wrong.