Cloudflare Anomalies End Time

[amandahmeng]

Many of the cloudflare anomalies have an end time of "now" UTC. Why? Can we fix this?

[ylw-PotatoTornado]

Upon investigation, this is unlikely an issue in Aggie but the data source from Cloudflare. Solutions can be discussed further in meeting.

Investigated Data Sources:

1. (Source of Truth) Cloudflare Radar Website - Traffic Anomalies Page
2. (Email Subscription) Cloudflare Anomalies Email Subscription
3. (Aggie) Aggie data sourced from cloudflare

Investigated Time Range:
October 1st - December 6th

Investigation Result:
-all based on time range from UTC Oct 1st to UTC Dec 6th)-

1. Out of all 25 anomalies emails, only 1 is now visible on cloudflare radar website (the one by Mobinnet on Nov 4th)
2. Out of all 27 anomalies shown on Aggie, only 1 is now visible on cloudflare radar website (the one by Mobinet on Nov 4th)
   Conclusion: The result of Aggie and Email Subscription matched. However, the reason why anomalies reported via email eventually disappear is something awaiting confirmation with Cloudflare and see if there's any action we can take to mitigate this issue.

Possible Reasons:

1. Cloudflare may have some logic updates on whether to show specific reports (e.g. if an event was detected but later verified as "false positive", they may remove it from the traffic anomalies? not sure about this).
2. If 1. holds, this explains why most events show no ending time on Aggie because: the API logic is when we query traffic anomalies between timestamp A and timestamp B from cloudflare radar API, cloudflare returns events whose starting time between A and B, or ending time between A and B, if an event is non-terminating, its ending time would be null.
   Therefore all events, when they started, would be captured by Aggie. However, if they were later removed from the traffic anomalies pool due to some reason, the API would never be able to capture ending time for all these events any more, leaving their ending time as "now (representing null ending time, non-terminating)"

Possible Solutions (Awaiting Further Discussion):

1. discuss business requirement first: do we want to keep anomalies that were eventually removed by cloudflare in Aggie? (to show they "once alerted"?)
2. If Yes -> we can assign a temporary timestamp (the time we fetched the data) to each event. If the event was eventually confirmed as True Positive and kept in Cloudflare, then based on current Aggie logic, the ending time will be updated to true ending time as well. If removed from cloudflare, the ending time will remain as the data fetch time in Aggie.
3. If Not -> I will further investigate, but current API does not support detecting such removal of anomalies unless we repeatedly fetch updates for all non-terminating events and marked them as false positive after duration exceeding some threshold.