You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have two stats output models: the dagmulticaster model (per-thread files that are overwritten every minute), and the corsarowdcap model (a stats file that is written alongside data files).
This leaves corsarotagger and corsarotrace.
Probably corsarotagger should use the dagmulticaster model since it doesn't output any data files, and ideally shouldn't get stuck if there is some issue with the time series platform.
Since corsarotrace already generates output (either files or time series), then it would be nice if its stats could be output using the same infrastructure. The flowtuple and dos instances could create stats files that go along with the data files, but the time series (report) instances could be configured to output capture stats using libtimeseries.
The text was updated successfully, but these errors were encountered:
We currently have two stats output models: the dagmulticaster model (per-thread files that are overwritten every minute), and the corsarowdcap model (a stats file that is written alongside data files).
This leaves corsarotagger and corsarotrace.
Probably corsarotagger should use the dagmulticaster model since it doesn't output any data files, and ideally shouldn't get stuck if there is some issue with the time series platform.
Since corsarotrace already generates output (either files or time series), then it would be nice if its stats could be output using the same infrastructure. The flowtuple and dos instances could create stats files that go along with the data files, but the time series (report) instances could be configured to output capture stats using libtimeseries.
The text was updated successfully, but these errors were encountered: