Network Data Flow Collection Methods for Cybersecurity: A Systematic Literature Review

Abstract

Network flow collection has become a cornerstone of cyber defence, yet the literature still lacks a consolidated view of which technologies are effective across different environments and conditions. We conducted a systematic review of 362 publications indexed in six digital libraries between January 2019 and July 2025, of which 51 met PRISMA 2020 eligibility criteria. All extraction materials are archived on OSF. NetFlow derivatives appear in 62.7% of the studies, IPFIX in 45.1%, INT/P4 or OpenFlow mirroring in 17.6%, and sFlow in 9.8%, with totals exceeding 100% because several papers evaluate multiple protocols. In total, 17 of the 51 studies (33.3%) tested production links of at least 40 Gbps, while others remained in laboratory settings. Fewer than half reported packet-loss thresholds or privacy controls, and none adopted a shared benchmark suite. These findings highlight trade-offs between throughput, fidelity, computational cost, and privacy, as well as gaps in encrypted-traffic support and GDPR-compliant anonymisation. Most importantly, our synthesis demonstrates that flow-collection methods directly shape what can be detected: some exporters are effective for volumetric attacks such as DDoS, while others enable visibility into brute-force authentication, botnets, or IoT malware. In other words, the choice of telemetry technology determines which threats and anomalous behaviours remain visible or hidden to defenders. By mapping technologies, metrics, and gaps, this review provides a single reference point for researchers, engineers, and regulators facing the challenges of flow-aware cybersecurity.

1. Introduction

Modern networks can benefit from real-time visibility to keep pace with backbone link speeds and to support the detection of cyber threats and anomalous behaviors. Flow telemetry, which exports compact records through technologies such as NetFlow, sFlow, and IP Flow Information Export (IPFIX), offers a practical way to meet this need. These records summarize packet sequences while preserving attributes essential for cybersecurity analysis. They already support monitoring tasks that process tens or even hundreds of gigabits per second in carrier, campus, and cloud environments [1,2,3,4,5].

The conversion of flow records into actionable intelligence continues to present significant challenges. Aggressive sampling has been shown to reduce detection rates by up to 45% [6], and poorly tuned time-outs have been observed to overwhelm collectors during periods of high traffic [7]. Privacy regulations introduce additional obstacles: European providers employ prefix-preserving hashes for Secure Shell (SSH) and Domain Name System (DNS) records, yet encounter persistent re-identification risk [4,8].

Researchers are exploring techniques optimized for hardware, with the objective of maintaining operational capacity in the face of high-speed traffic while minimizing on-chip memory utilization. FPGA-accelerated probes are a recent development that has the potential to transform the field of network analysis. By moving packet counting into reconfigurable logic chips, these probes free the main CPU to focus on other tasks, thereby enhancing the overall efficiency of network operations. Programmable data planes, written in the P4 language, enable network switches to inspect and label packets in real time, obviating the need for traffic to leave the device for analysis. Probabilistic sketches, defined as compact data structures that store statistical estimates such as the number of connections per IP address, have been developed to replace full flow tables with lightweight counters. When considered collectively, these three approaches, as reported in recent studies [9,10,11,12], function within the limited static random-access memory (SRAM) capacity of switches while still achieving the requisite accuracy for reliable anomaly detection on links operating at speeds ranging from tens to hundreds of gigabits per second.

Several studies have employed machine-learning models to analyze the collected flows. In Software-Defined Networking (SDN) environments, adaptive-sampling techniques have been shown to achieve detection rates above 95% for malicious traffic [13]. Other studies have employed ensembles of decision trees trained on flow statistics and have reported analogous performance on backbone links [14]. However, the release of source code or complete datasets is rare among authors, which undermines the reproducibility of research findings [15,16].

Previous reviews have largely focused on algorithms or protocol taxonomies, rarely linking collection technology, feature engineering, and deployment evidence in a single view. Building on these limitations, this study conducted a systematic literature review (SLR), guided by the PRISMA protocol and encompassing publications from January 2019 to July 2025. The review examines technologies, validation settings, metrics, and outstanding challenges, addressing four research questions:

• RQ1: Which technologies and architectures currently support flow collection for cybersecurity?
• RQ2: How do different flow-collection technologies compare in terms of data acquisition methods, advantages, limitations, and applicability to cybersecurity scenarios?
• RQ3: Which performance metrics are reported, and how consistent are they?
• RQ4: Which open challenges (scalability, privacy, regulatory compliance, benchmark availability) persist?

By mapping objectives, exporters, feature pipelines, and bias risks, this review provides an integrated evidence base for researchers, operators, and policymakers interested in flow-aware defences. The subsequent sections are dedicated to the following: Section 2 details the methodology; Section 3 presents the results; Section 4 discusses gaps and opportunities; and Section 5 offers recommendations for future research.

2. Materials and Methods

2.1. Review Protocol

This systematic review was conducted with the aim of identifying and analyzing network flow data collection methods to be used in the context of cybersecurity. The process was structured into three main phases: study identification, study selection and data analysis, aiming for rigor and reproducibility throughout all stages.

The full protocol of this review was retrospectively registered on the Open Science Framework (OSF, https://doi.org/10.17605/OSF.IO/MJ4XP (accessed on 14 September 2025)).

2.2. Identification of Studies

2.2.1. Databases and Search Strategy

The time frame (2019–2025) was established to cover the most recent seven years of publications, an interval widely adopted in systematic reviews in software engineering and networking. Although technologies such as NetFlow and sFlow were proposed decades ago, the purpose of this review is to synthesize recent evidence in the context of rapid transformation, including the growth of 40/100 Gbps link speeds and regulatory compliance requirements such as GDPR. Studies published prior to this period were regarded as historical, but they tend not to address the technical and regulatory challenges that have become more prominent in recent years. The total of 51 included articles is consistent with the standard observed in systematic reviews in this field, where methodological quality carries more weight than the absolute number of studies.

The search was conducted across major reference repositories in engineering and computing, including ACM Digital Library [17], IEEE Xplore [18], ScienceDirect [19], SpringerLink [20], Web of Science [21], and Scopus [22], covering the period from 1 January 2019 to 31 July 2025. All search queries were executed and the strategy was validated between 3 January 2025 and 1 August 2025 (

Table 1. Summary of database coverage, last search date, and total records retrieved. Dates follow ISO 8601 format (YYYY-MM-DD) to avoid ambiguity.

Database	Time Coverage	Last Search	Records Retrieved
ACM Digital Library	2019-01-01–2025-07-31	2025-08-01	36
IEEE Xplore	2019-01-01–2025-07-31	2025-08-01	9
ScienceDirect	2019-01-01–2025-07-31	2025-08-01	75
SpringerLink	2019-01-01–2025-07-31	2025-08-01	18
Web of Science	2019-01-01–2025-07-31	2025-08-01	6
Scopus	2019-01-01–2025-07-31	2025-08-01	218
Total			362

).

To ensure the inclusion of relevant studies, we adopted a search strategy using key terms combined with Boolean operators. The strategy was adjusted for each database, taking into account its specificities. Example search string:

((“NetFlow” AND “sFlow”) OR (“NetFlow” AND “IPFIX”) OR (“sFlow” AND “IPFIX”)) AND (“intrusion detection” OR “anomaly detection” OR cybersecurity OR “information security”)

The search string was designed to identify studies dealing specifically with network flow data collection methods applied to cybersecurity. Terms such as NetFlow, sFlow, and IPFIX have been included to ensure that the search focuses on key technologies in network data collection. In addition, the terms “intrusion detection”, “anomaly detection”, “cybersecurity”, “cyber security”, and “information security” have been added to narrow down information security applications. This combination ensures the relevance of the results, aligning them with the study’s objective of reviewing network data collection methods to identify, mitigate, and analyze cyber threats.

The search string was structured to combine network flow data collection technologies in pairs, specifically NetFlow, sFlow, and IPFIX, using the OR operator to ensure coverage of all combinations between two technologies at a time. This segment was then combined using the AND operator with thematic terms related to cybersecurity (such as intrusion detection, anomaly detection, and information security). This approach balances inclusiveness with relevance, ensuring that retrieved studies address at least two core technologies in conjunction with practical cybersecurity applications.

2.2.2. Additional Filters

• Publications from 1 January 2019 to 31 July 2025, reflecting the latest advances and current trends in data flow collection technologies in the field of cybersecurity.
• Peer-reviewed articles guarantee the scientific and methodological quality of the study.
• Studies in English, the predominant language in scientific literature.

2.2.3. Criteria for Inclusion

• Peer-reviewed publications (articles or conference papers) published between January 2019 and July 2025.
• Studies that address the use of specific network flow collection technologies, such as NetFlow, sFlow, IPFIX, or equivalent, in the context of cybersecurity.
• English language and full text available.
• Proposing, implementing, or evaluating data collection methods applied to cybersecurity (intrusion detection, incident response, traffic monitoring, etc.).
• The study must contribute to or discuss the data collection layer, not merely the subsequent processing or analysis stages.

2.2.4. Criteria for Exclusion

• Duplicate documents.
• Editorials, tutorials, and summaries.
• Studies outside the scope of cybersecurity or that do not address network flow collection.
• Articles without a relevant technical approach, which do not present methods applicable to data collection.
• Papers that do not deal with specific technologies, such as NetFlow, sFlow, IPFIX, or equivalent.
• Article unavailable: Studies whose full text could not be obtained.

2.3. Study Selection Process

The selection process was carried out in two main stages:

2.3.1. Initial Screening

• Preliminary analysis: The title, abstract, introduction, graphs, tables, images and conclusion of the studies were analyzed to identify those that were potentially relevant.
• Elimination of irrelevant studies: Studies that clearly did not meet the inclusion criteria or met the exclusion criteria were excluded at this stage.
• Selection for full reading: Studies that showed partial or total relevance in any of the elements assessed were selected for detailed analysis.

2.3.2. Full Text Evaluation

• Detailed analysis: Each selected study was fully reviewed to confirm its relevance and alignment with the objectives of the review, considering content, methods, and results presented.
• Collaborative process: All stages were carried out independently by two researchers.

2.4. Data Analysis

2.4.1. Data Extraction

To ensure consistency and relevance in the analysis of the included studies, we used a standardized data extraction model focusing on the following categories:

• Bibliographic information: We have recorded the authors, title, year of publication, and source of the study in order to contextualize the origin and credibility of the work.
• Methodologies: We mapped the techniques and tools used to collect data from the data flow.
• Applications: We analyzed the context in which the methods were applied.
• Results: We evaluated the effectiveness of the proposed methods, their practical and theoretical limitations.

2.4.2. Tabulation and Comparison Process

After the initial extraction, we organized the data in a table to allow a structured and comparative analysis between the studies. This approach made it easier to identify patterns, trends, and gaps in the literature analyzed.

2.4.3. Iterative Review of Studies

Whenever necessary, we revisited the studies to clarify doubts or supplement information. This process ensured the accuracy and comprehensiveness of the analysis.

2.4.4. Tools Used

• Zotero [23]: We use it to manage bibliographical references and store the articles analyzed.
• Microsoft Excel: We structured and categorized the extracted data in Excel, allowing for comparative analysis and the visualization of trends.
• StArt [24]: Tool used to support the conduct of the systematic literature review, with functionalities for selecting, excluding, categorizing, and analyzing articles.

2.4.5. Categorization and Synthesis

We organized the data into five main categories, reflecting the results of the analysis: study objectives, data collection methods, data extraction processes, comparison of collection technologies, and challenges and practical implementations. This categorization allowed for a comprehensive and detailed analysis, in line with the objectives of the systematic review.

2.5. Quality Assessment and Risk of Bias

To ensure the methodological quality of the included studies and the reliability of the extracted data, two independent reviewers (R1 and R2) applied a structured checklist based on five domains adapted from Kitchenham et al. [25]:

• Clarity of context;
• Transparency of metrics;
• Validation process;
• Reproducibility;
• Declaration of conflict of interest.

Each domain was evaluated based on the following criteria:

• 0: criterion fully met;
• 1: partially met;
• 2: not answered.

The sum of the scores resulted in a total score for each study (0 to 10), used to classify the risk of bias into three levels:

• Low risk of bias: total score from 0 to 2;
• Moderate risk of bias: total score of 3 to 5;
• High risk of bias: total score equal to or greater than 6.

Before the instrument was fully applied, a pilot study was carried out with five selected articles to calibrate the criteria and ensure consistency between the reviewers. The evaluations were conducted independently and recorded on separate spreadsheets (R1 and R2). Disagreements were discussed and resolved by consensus, as documented in the “Consensus” tab of the spreadsheet provided as Supplementary Material (Table S2: Risk_of_Bias_Evaluation_51_Studies.xlsx).

The full assessment, including scores by domain, detailed justifications, and final risk classification for each of the 51 studies analyzed, is available on the Open Science Framework (OSF): https://doi.org/10.17605/OSF.IO/MJ4XP (accessed on 14 September 2025).

All decisions related to the inclusion, exclusion and classification of studies were recorded and summarized in the PRISMA flowchart (Figure 1), which illustrates the process of screening the 362 records initially identified until the final selection of 51 articles for analysis. The full review protocol is available on the Open Science Framework (https://doi.org/10.17605/OSF.IO/MJ4XP (accessed on 14 September 2025)).

2.6. Characterization of the Selected Studies

Based on the inclusion and data extraction criteria previously described, the 51 selected articles were organized in a table containing the following information: authors, year of publication, main technology analyzed, validation environment used, and the main evaluation metrics used in the studies. This systematization aims to facilitate comparison between the studies and identify methodological patterns, gaps, and good practices in the area of data collection for cybersecurity.

Table 2. Distribution of data-collection technologies referenced across the 51 primary studies. Percentages indicate the share of papers that employ (or explicitly analyze) each technology. One study may appear in multiple rows when it compares or combines techniques.

Technology Category	Share of Papers (%)	ID Papers
NetFlow (v5/v9, xFlow derivatives)	62.7	[1,2,4,6,7,8,13,14,16,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49]
IPFIX/IPFIX-based probes	45.1	[2,4,5,6,8,15,16,27,28,30,33,35,36,37,39,40,41,46,47,49,50,51,52]
sFlow exporters/adaptive polling	9.8	[3,13,16,28,53]
INT/P4 sketches/OpenFlow mirroring	17.6	[10,11,12,54,55,56,57,58,59]
Other (LTE adaptive collectors, FPGA meters, trace generators, MIME sketch, etc.)	3.9	[9,60]

presents a summary of the characterization of the 51 studies selected in this review. The full version is available as Supplementary Material (Table S1: Data_Extraction_Table_51_Studies.xlsx) on the Open Science Framework (https://doi.org/10.17605/OSF.IO/MJ4XP (accessed on 14 September 2025)).

3. Results

3.1. General Characteristics of the Studies

In this section, we present a descriptive analysis of the selected studies based on their distribution by year of publication. Figure 2 illustrates this distribution, organizing the articles included in this systematic review between the years 2019 and 2025.

As illustrated in Figure 2, the number of relevant publications increased significantly between 2019 and 2020, reaching a peak of 12 articles in 2020. This trend may reflect a growing interest in cybersecurity telemetry during the early phase of that period. A relative consistency can be observed from 2021 to 2023, with eight to nine articles per year, followed by a slight decrease in 2024 and a provisional count of only two articles in 2025 (considering partial data until July). This distribution suggests that the topic has maintained a stable research output, though more recent trends will require further observation as 2025 progresses.

3.2. Main Results

The selected studies present a range of findings related to network data collection strategies for cybersecurity purposes. To facilitate a structured and comparative analysis, the main results have been categorized into five analytical dimensions: (i) study objectives, (ii) data collection methods, (iii) data extraction processes, (iv) comparison of collection technologies, and (v) challenges and practical implementations.

3.2.1. Study Objectives

The literature reviewed pursues a shared objective: to make network-flow telemetry a dependable foundation for cyber-defence. Across the 51 primary studies, authors framed their work as a response to rising attack volumes, expanding link speeds, and the need for actionable, low-latency indicators. Several studies, including Abramov et al. [1], Jirsik et al. [26], and Watkins et al. [27], define success as the reliable extraction of flow attributes that preserve threat context while remaining manageable for downstream analysis. Whether applied to core routers, SDN infrastructures, or cloud environments, these works converge on aligning collection fidelity with operational constraints, positioning telemetry as the first link in the security analytics chain.

Four recurring research aims emerged. Throughput and scalability dominate early discussions: Bhattacharjee et al. [2] and Pesek et al. [49] design collection pipelines that sustain tens to hundreds of gigabits per second without packet loss or exporter overload, showing that hardware-assisted probes and compressive sketches can export at line rate on 100 Gbps links by reducing per-flow state and exploiting parallelism. Detection accuracy forms a second theme; Campazas-Vega et al. [29] and Jafarian et al. [14] demonstrate that richer feature sets or adaptive sampling improve the identification of heavy hitters, DDoS bursts, and steganographic channels, with experiments on ISP backbones and emulated SDN testbeds pushing F1 Scores above 95% while controlling false alarms. A third focus is resource-efficient telemetry: Campazas-Vega et al. [6], Lin et al. [12], and Niknami et al. [30] propose dynamic sampling, two-layer sketches, and flow-aware compression that cut CPU and memory footprints without losing critical detail. Finally, policy and privacy compliance attracts a smaller but significant cluster; Fejrskov et al. [8] and Čeleda et al. [4] develop anonymisation policies, SSH-specific extensions, and configurable export filters to balance security insight with confidentiality obligations.

Comparative inspection reveals temporal and technological shifts in emphasis. Early work from 2019 to 2020, such as studies by Abramov et al. [1], proved that NetFlow and IPFIX could scale to campus and backbone speeds, whereas later contributions by Gao et al. [10] and Li et al. [11] pivot toward P4-based INT and switch-embedded sketches that lighten exporter workloads. Although accuracy improvement and scalability receive consistent attention, objectives linked to privacy, regulatory alignment, and reproducible benchmarking appear in only a handful of papers, signalling room for deeper exploration. Moreover, few studies explicitly connect collection goals to the robustness of downstream machine-learning models, leaving open questions about end-to-end effectiveness. These gaps motivate the detailed examination of collection methods in Section 3.2.2.

3.2.2. Data Collection Methods (RQ1: Which Technologies and Architectures Currently Support Flow Collection for Cybersecurity?)

This section addresses RQ1 by identifying the main technologies and architectures that currently support flow collection for cybersecurity. The evidence from the 51 studies shows a spectrum from classical NetFlow/IPFIX exporters to emerging INT/P4 and sketch-based collectors, implemented in software probes, router ASICs, programmable switches, and FPGA accelerators.

The studies describe data-collection methods that span from software probes running on commodity servers to hardware-assisted collectors embedded in switch data planes. Lin et al. [12] and Campazas-Vega et al. [6] illustrate the early phase, which relied on conventional NetFlow and IPFIX exporters. More recent work by Čeleda et al. [4] and Husák et al. [32] combines adaptive sampling with programmable data planes to keep pace with ever-faster links. Whether on campus backbones, nationwide carriers, or cloud fabrics, the common goal is to expose flow semantics without harming forwarding performance.

Table 3. Performance metrics reported in flow-collection studies, with definitions and observed outcomes.

Article	Metric	How the Metric Works	Analysis of Result
Velan & Čeleda (2019) [4]	Packet Processing Rate (pps)	Tracks rate of packet inspection and flow construction including application-layer parsing, measured in packets per second	Application-aware monitoring with optimization techniques sustained ~1 Mpps on a single core versus ~0.2 Mpps baseline, indicating a 5× performance gain while enriching flows with application metadata
Wrona & Zadník (2019) [5]	Query Latency (s)	Records end-to-end latency of interactive queries on distributed flow records platform versus Hadoop/MapReduce baseline	Distributed system yielded query latencies <1 s compared to 20–35 s on 6-node MapReduce cluster, demonstrating >20× speed-up for typical aggregation and Top-N queries with minimal overhead
Campazas-Vega et al. (2023) [6]	Sampling Rate	The proportion of packets selected for flow generation (e.g., 1 in every 250, 500, or 1000 packets is sampled).	As sampling becomes sparser, malicious flow details are lost. Detection remains high up to a 1/250 rate; at 1/500 some models (LR, LSVC) fall below 64% accuracy, while at 1/1000 only KNN, MLP, and RF maintain above 90% accuracy.
Sateesan et al. (2021) [9]	Throughput (Mpps)	Measures millions of packets per second processed by the A-CM sketch on FPGA; counted as number of flow updates per second under maximum line-rate traffic	A-CM sketch achieved up to 454 Mpps throughput with 5 clock-cycle update latency, outperforming prior FPGA-based sketches by 20–30% in both throughput and memory efficiency
Li et al. (2024) [11]	Flow reconstruction accuracy	Compresses flow counts in the switch and reconstructs them at the controller	Recovers nearly all flows with under 10% error using only 24 KB of memory
Lin & Lai (2022) [12]	Average error by priority class	Divides flows into priority classes and applies separate sketches to reduce collisions	Reduces error for high-priority flows by up to 57% and achieves up to 3× higher throughput than generic sketches
Matoušek et al. (2020) [15]	Flow delivery latency	Measures time delay between flow generation at the device and its arrival at the NetFlow collector	Average latency under 5 ms with low jitter, meeting industrial control requirements
Niknami et al. (2024) [30]	Adaptive sampling rate	Dynamically adjusts the fraction of packets sampled per flow based on detection feedback	Detects 90% of anomalies using roughly half the packets required by static sampling, cutting overhead
Fejrskov et al. (2022) [39]	Sampling rate 1:1024	Only 1 out of every 1024 flows is recorded in the NetFlow logs; the remaining flows are discarded before feature extraction.	This high sampling rate reduces storage requirements and protects privacy and scalability, but may omit low-volume or short-lived flows.
Janati-Idrissi et al. (2025) [42]	Number of flows expired per timeout setting	NetFlow/IPFIX records are collected under different active and idle timeout values. The metric counts how many flow records expire before reporting under each setting.	Flow count varied by up to 15% depending on timeout configuration, showing that timeout parameters directly affect data completeness.
Komisarek et al. (2021) [45]	Sampling rate vs. volume of data collected	Various packet sampling schemes (e.g., 1:10, 1:100) are applied before NetFlow export. The metric measures the percentage reduction in captured packet volume.	A 1:100 sampling rate reduced data volume by up to 90% while retaining at least 80% of detection capability, illustrating the trade-off between collection overhead and detection efficacy.
Ndonda & Sadre (2020) [48]	Traffic pattern fidelity	Generates synthetic traffic following observed packet-size and inter-packet time distributions	Simulated traffic matches over 98% of real trace characteristics across multiple scenarios
Ujjan et al. (2020) [53]	True Positive Rate (TPR) vs. False Positive Rate (FPR)	Compares sFlow packet sampling (1:1256) against adaptive polling by measuring ratio of correctly detected malicious flows (TPR) and misclassified benign flows (FPR)	sFlow achieved TPR ≈ 95% with FPR ≈ 4%, while adaptive polling reached TPR ≈ 92% with FPR ≈ 5%. The sampling rate provided a better trade-off between overhead and detection quality
Lu et al. (2022) [57]	Entropy estimation quality	Tracks packet-size distribution over time windows to estimate entropy	Estimates are within 5% of the exact value while using minimal memory
Lu et al. (2022) [57]	Average entropy error	Filters out rare packets in the first layer, then computes entropy in the second layer	Maintains average error below 7% under high-volume conditions, demonstrating dataplane efficiency

reports the share of each technology between 2019 and 2025, a period in which researchers came to treat collection as an active part of security analytics, tuning export granularity to meet intrusion-detection latency targets.

Classic flow-export pipelines still anchor many deployments. Abramov et al. [1] show that NetFlow v5/v9 exporters on backbone routers can stay above twenty-five thousand flows per second by tuning sampling rates and timeout values. Fejrskov et al. [8] prefer IPFIX for its extensible templates, which let operators embed DNS or SSH fields without changing router firmware. Bhattacharjee et al. [2] and Pesek et al. [49] report that high-speed software appliances reach one hundred gigabits per second through NUMA pinning and zero-copy I/O, keeping packet loss below 0.5%. Placement also matters: Jirsik et al. [26] find that router ASICs give broad core visibility, whereas edge probes on OpenFlow switches isolate tenants and supply fine-grained exports for SDN policies.

To meet scale and fidelity at once, several teams embed sketches or programmable filters directly in the data plane. Li et al. [11] and Lin et al. [12] design switch-resident CS-Sketch and MC-Sketch structures that compress per-flow counters yet preserve heavy-hitter accuracy at line rate. Lu et al. [57] introduce a two-layer sketch that estimates entropy for anomaly detection while fitting strict byte budgets. Gao et al. [10] add INT telemetry to P4 pipelines, appending hop-level metadata that enables microsecond tracing of service-flow attacks. Niknami et al. [30] and Kim et al. [13] complement these ideas with distributed sampling that adjusts quotas to traffic volatility, cutting export volume by up to 50% without hurting recall.

Choosing a method always balances throughput, resource cost, and privacy exposure. Sateesan et al. [9] show that hardware probes surpass one hundred gigabits per second but depend on proprietary FPGA cards, while Moreno-Sancho et al. [47] observe that software exporters are easier to tune but consume more CPU. Few studies measure energy use or the impact of encryption, exposing a clear gap. Privacy-aware exporters that hash sensitive fields appear only sporadically, as reported by Čeleda et al. [4]. Standardised benchmarks for sampling bias also remain rare, underscoring the need for harmonised extraction pipelines discussed next in Section 3.2.3.

3.2.3. Data Extraction Processes and Metrics (RQ3: Which Performance Metrics Are Reported, and How Consistent Are They?)

This subsection addresses RQ3: Which performance metrics are reported, and how consistent are they? Flow-collection studies employ a wide range of evaluation practices, but the lack of uniform reporting standards hampers comparability. To provide a structured overview, Table 3 summarizes representative metrics, their operational principles, and the outcomes reported in the literature.

Feature extraction is the backbone of every analytic step that follows collection, because raw flow tuples alone seldom reveal behavioural nuances. Kim et al. [13] argue that poorly curated features amplify class imbalance and concept drift, so they treat extraction as a prerequisite for reliable anomaly detection. Borylo et al. [3] and Pesek et al. [49] relate their extraction choices to campus backbones and carrier networks, stressing that fast collection is useless without equally disciplined transformation pipelines.

Most preprocessing starts with time segmentation. Abramov et al. [34] and Gao et al. [55] favour fixed five-second sliding windows for high-speed probes, whereas Husák et al. [32] and Watkins et al. [27] prefer minute-level tumbling windows for long-horizon awareness. Several teams merge opposite-direction flows into bidirectional sessions to cut redundancy, a tactic validated on 100 Gbps traces by Čeleda et al. [4] and reproduced in FPGA capture pipelines by Sateesan et al. [9]. Label attribution usually relies on IDS alerts or manual review, but Jafarian et al. [14] and Niknami et al. [30] inject synthetic attacks to balance minority classes.

Feature-engineering depth varies. Full 84-field NetFlow templates are rare; instead, Li et al. [11] and Lin et al. [12] distil 20 to 40 statistics such as byte ratios, packet dispersion, and inter-arrival variance. Lu et al. [57] and Zhang et al. [54] add entropy-based descriptors in adaptive sketches for SDN fabrics. Erlacher et al. [50] and Ndonda et al. [48] enrich flows with packet-level details like TCP flag counts and TLS handshake times using IPFIXcol2 or custom Python 3.10.1 scripts.

One third of the studies augment baseline features with external data. Fejrskov et al. [39] and Moreno-Sancho et al. [47] align DNS logs to detect resolver hijacking. Danesh et al. [37] and Ujjan et al. [53] attach blacklist look-ups to flag cryptojacking with minimal overhead. Husák et al. [41] and Jare et al. [43] enrich host fingerprints with active Nmap scans or INT probes, though deployment and privacy concerns persist. Authors debate the trade-off between enrichment depth and real-time feasibility.

Reproducibility remains limited. Pesek et al. [49] and Wrona et al. [5] released their Spark-based extraction code, but most authors share only pseudocode or screenshots, as noted by Matoušek et al. [15] and Čeleda et al. [4]. Divergent field names and inconsistent label taxonomies hamper meta-analysis, highlighting the need for community-endorsed templates and public scripts. These issues set the stage for Section 3.2.4, where we compare collection technologies against the demands they place on extraction pipelines.

Beyond feature extraction, a critical dimension for answering RQ3 is the evaluation framework itself. Studies differ widely in the metrics they report—some use information-theoretic indicators such as entropy, others rely on standard machine learning measures such as accuracy, precision, recall, and false alarm rate, while only a minority report system-level indicators such as throughput, latency, or energy cost. This heterogeneity makes it difficult to compare results across studies and underscores the lack of a common benchmark suite.

To illustrate this diversity, Table 3 summarizes representative examples of performance metrics reported in flow-collection studies, explaining how each metric works and what outcomes were achieved. The overview highlights both the variety of evaluation practices and the absence of a consistent reporting standard across the literature.

3.2.4. Comparison of Collection Technologies E Uso Em Cybersecurity (RQ2: How Do Different Flow-Collection Technologies Compare in Terms of Data Acquisition Methods, Advantages, Limitations, and Applicability to Cybersecurity Scenarios?)

This section addresses RQ2 by providing a consolidated comparative analysis of flow-collection technologies, discussing how they acquire data, their advantages and limitations, and their applicability across cybersecurity scenarios.

Effective telemetry depends on choosing collection technologies that balance export speed, measurement fidelity, and operational cost. Bhattacharjee et al. [2] note that high-throughput backbones must capture one hundred gigabits per second without losing packets, whereas Čeleda et al. [4] show that campus networks can accept moderate sampling if it lightens the analyzer load. Edge deployments often favour minimal CPU use and straightforward configuration. Judging a technology’s fit, therefore, means understanding how it navigates these trade-offs across diverse cybersecurity scenarios.

NetFlow, IPFIX, and sFlow still serve as the principal workhorses. Bhattacharjee et al. [2] demonstrate a software probe that reaches one hundred gigabits per second by parallelising flow aggregation, while Čeleda et al. [4] enrich SSH traffic with custom IPFIX options at negligible overhead. Erlacher et al. [50] push extensibility further by integrating signature matching directly into an IPFIX pipeline. Newer approaches adopt in-band metadata: Gao et al. [10] use INT within P4 data planes to record per-hop delays at nanosecond precision on ten-gigabit links, and Sadrhaghighi et al. [58] employ OpenFlow mirroring for rule-driven export, although coverage drops when multiple taps compete for switch resources.

Hardware-assisted sketches address memory limits by compressing counters inside programmable devices. Sateesan et al. [9] measure two-hundred-gigabit flows with sub-microsecond latency on FPGA meters. Li et al. [11] cut SRAM demand in half with CS-Sketch on Tofino switches while keeping relative error below 1%, and Lin et al. [12] extend the idea with MC-Sketch to track large “elephant” flows and aggregate the long tail.

Each option carries trade-offs. Exporters tuned for backbone speed often sacrifice attribute richness, whereas in-band telemetry offers fine path visibility at the cost of larger packets. Niknami et al. [30] and Wrona et al. [5] observe that studies rarely quantify privacy controls or energy footprints, leaving open questions about sustainable deployment in power-sensitive cores. Reproducibility also lags: only a handful of authors release open-source exporters or packet traces [16], and poor cross-format compatibility complicates multi-vendor tooling. These gaps frame Section 3.2.5, which examines the implementation challenges and emerging solutions aimed at closing them.

Each approach entails trade-offs: high-speed exporters sacrifice attribute richness, whereas in-band telemetry adds overhead. Studies such as Niknami et al. [30] and Wrona et al. [5] highlight the absence of metrics on energy consumption and privacy controls.

To reinforce the focus of this review, we present below a consolidated comparative analysis of the main flow-collection technologies. Each method is described in terms of how it performs collection, its advantages and disadvantages, suitable use cases, and open challenges.

The comparison in

Table 4. Summary of these aspects, comparing the principal flow-collection technologies, their characteristics, limitations, and recommended uses according to the analyzed literature.

Technology	Main Characteristics (According to the Literature)	Limitations (According to the Literature)	Suggested Use (According to the Literature)	Types of Attacks Reported in the Studies
NetFlow (v5/v9)	Aggregates packets into 5-tuple flows (source/destination IP, ports, protocol), exporting statistics such as bytes, packets, duration, and TCP flags; supports NetFlow v5 (fixed), v9 (template-based), and IPFIX (IETF-standard with extensible templates for additional metrics like DNS/HTTP/TLS); low overhead on routers and switches (ASIC-compatible); allows statistical sampling (1:N) to reduce cost; broad interoperability and native vendor support; integration with modern pipelines (Logstash, ClickHouse, Grafana) and automation frameworks (e.g., Ansible).	Does not capture payload, only header metadata; sensitive to encrypted traffic; heavily dependent on sampling configuration (may miss short flows and introduces a trade-off between precision and performance); large data volumes can saturate collectors and require Big-Data infrastructure; large template sets increase extraction latency; legacy versions (v5) are inflexible; complex tuning needed for clustering and dynamic feature definition; traditional tools (e.g., nfdump) become bottlenecks under high-volume collection.	Traffic monitoring in backbones, NRENs, ISPs, campus networks, and datacenters; network performance analysis, traffic engineering, and capacity planning; real-time detection of DDoS, port scans, brute-force attacks, botnets, and volumetric anomalies; forensic and historical analysis; protocol and policy auditing (e.g., SSH, DNS); identification of “heavy hitters” and “top talkers” for prioritization and troubleshooting; integration with IDS/IPS for alert correlation; scenarios where DPI is infeasible but high-volume visibility is essential.	Cryptomining/Cryptojacking Denial of Service (DoS)/Distributed DoS (DDoS) Port scanning/Network reconnaissance Brute-force authentication attacks Web application attacks Malware & exploits Botnet-related activity DNS-based attacks Network protocol abuse Fuzzers (automated vulnerability discovery). Web crawling/malicious scanning. Multihop (malicious routing/relay). WarezClient/WarezMaster (pirated software distribution). Recorded live user interaction (human-driven intrusion). Generic intrusion/generic attacks. Analysis (malicious analysis tools). IoT malware and targeted IoT attacks.
IPFIX	IETF-standardized, extensible flow export protocol (RFC 5101/7011) evolved from NetFlow; template-based design allows customizable fields (L2–L7, DNS, SSH, TLS, HTTP), user-defined data types, and bidirectional aggregation; widely supported in commercial routers/switches; enables multi-layer monitoring, distributed telemetry, and real-time integration with big-data pipelines (e.g., Elasticsearch, Kafka, IPFIXcol2).	Higher processing and memory overhead at collectors; dependency on template synchronization between exporters/collectors; packet loss of templates may delay decoding; non-encrypted messages raise privacy concerns; visibility limited to headers (no payload); accuracy reduced under aggressive sampling; interoperability varies across vendors; NAT/dynamic addressing complicates correlation; requires tuning of timeouts and template management.	Large-scale traffic monitoring in ISPs, NRENs, and corporate networks; anomaly and attack detection (DoS/DDoS, SSH brute force, DNS hijacking, cryptojacking); capacity planning and SLA monitoring; forensic analysis and long-term data retention; telemetry in SDN and IoT/ICS environments; privacy-compliant monitoring in regulated contexts (e.g., ePrivacy in the EU); situations where DPI is infeasible but enriched flow metadata is needed.	Cryptojacking/Cryptomining Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) Port scanning/network probing SSH brute-force attacks Botnet command-and-control communication Worm propagation Intrusion attempts/unauthorized network infiltration Web application attacks DNS-based attacks IoT malware and IoT-targeted attacks Traffic obfuscation and tunneling
sFlow	Industry-standard packet sampling protocol (1-in-N header sampling) that exports UDP datagrams containing flow statistics and interface counters; lightweight on CPU/memory; widely supported across vendors and interoperable with SDN/OpenFlow; scalable for high-speed and heterogeneous environments (cloud, data centers, IoT).	Sampling reduces granularity and may miss short/low-rate flows or rare anomalies; precision highly sensitive to sampling rate (too high overloads collectors, too low loses detail); no payload visibility; limited view of intra-switch traffic.	High-speed networks where full DPI is infeasible; large-scale traffic monitoring in ISPs, SDN/NFV, campus and data centers; capacity planning and anomaly detection (e.g., DDoS); real-time statistical analysis and SLA monitoring in resource-constrained switches.	Denial of Service (DoS)/Distributed Denial of Service (DDoS) Brute-force authentication attacks Botnet-related activity Cryptomining/Cryptojacking DNS-based attacks IoT malware and IoT-targeted attacks Evasion/traffic obfuscation Generic intrusion detection (Intrusion attempts)
INT/P4 (In-band Network Telemetry)	In-band telemetry (INT) integrated with P4 forwarding, embedding hop-level metadata (timestamps, queue states, IDs) into packets; supports postcard model and on-demand activation; hierarchical multilayer structure with adaptive sampling to reduce controller load.	Requires P4-enabled switches (not legacy hardware); adds per-hop processing overhead; complex configuration of on-demand policies and metadata; centralized collection/aggregation needed; still mostly at prototype stage with limited large-scale deployments.	High-performance SDN environments with P4 adoption; critical applications needing fine-grained telemetry (e.g., aviation, data centers); scenarios benefiting from on-demand monitoring to cut overhead; integration with OpenFlow/Floodlight for fast anomaly detection and rerouting.	Distributed Denial of Service (DDoS) attacks General network anomalies Port scanning/network probing
Sketches (CS, MC, Filter, MIME)	Compact counter-based data structures (Count-Min, Elastic, MV, UnivMon, CS, Filter, MC, A-CM, etc.) with O(1) per-packet updates; support heavy-hitter, heavy-changer, entropy, and superspreader detection; adaptable via multi-layer designs, bidirectional counters, TCAM offload, or FPGA acceleration to reach hundreds of Gbps.	Accuracy drops for small (“mice”) flows due to hash collisions; trade-off between memory size and error; some designs require specialized hardware (TCAM, FPGA, programmable switches); increased complexity in multi-layer or reconstruction schemes; added controller overhead in full-flow recovery.	High-speed networks (100 Gbps+ backbones, ISPs, datacenters) requiring inline, low-latency flow measurement; detection of heavy hitters, abrupt traffic shifts, superspreaders, and entropy anomalies; suitable for SDN/programmable switches or FPGA-based deployments where precise telemetry and scalable flow monitoring are critical.	Heavy-hitter detection (volumetric flows/hosts, e.g., volumetric DDoS) Heavy-change detection (sudden shifts in traffic distributions) Superspreader detection (anomalous flows indicative of port scanning or DDoS) Denial of Service (DoS/DDoS) Botnet Cryptomining/Cryptojacking Malicious DNS (DNS malware/hijacking) Network Intrusion (generic intrusion) IoT Malware Tor traffic VPN traffic
FPGA Probes	Hardware-based packet and flow capture directly on FPGA NICs with on-chip caching and parallel pipelines, enabling line-rate processing from 1 Gbps (legacy NetFPGA) to 200+ Gbps in modern platforms; supports pre-filtering, sampling, summarization, and even DPI offload to reduce host CPU load.	High cost of specialized FPGA hardware; limited on-chip memory that can bottleneck under high flow counts; complex development and maintenance (HDL, firmware updates, vendor toolchains); less flexible than software-only collectors.	High-speed backbone or datacenter links (≥10 Gbps) requiring inline flow monitoring and very low latency; detection of elephant flows and volumetric attacks; environments where CPU offload is critical (e.g., inline IDS/NIDS, DPI acceleration, ISP/Tier-1 operators).	Generic intrusion/generic attacks.

highlights that no single flow-collection technology is universally optimal; each offers distinct strengths and weaknesses shaped by its design. NetFlow and IPFIX remain the most widely deployed, balancing interoperability and extensibility, but at the cost of sampling sensitivity and collector overhead. sFlow stands out for scalability and low device impact, though at the expense of granularity. INT/P4 and Sketches provide cutting-edge precision and adaptability in programmable networks, yet are still constrained by deployment maturity and hardware requirements. FPGA probes deliver unmatched throughput and latency but introduce cost and complexity barriers. These trade-offs confirm that technology selection must align with the operational context, balancing scalability, accuracy, and resource constraints.

3.2.5. Challenges and Practical Implementations (RQ4: Which Open Challenges (Scalability, Privacy, Regulatory Compliance, Benchmark Availability) Persist?)

This section addresses RQ4 by analyzing the open challenges that persist in flow collection for cybersecurity, namely scalability, privacy, regulatory compliance, and benchmark availability.

Designing deployable defences requires a clear view of the limits that flow collectors face. Čeleda et al. [4] show that, on campus backbones, export latency can exceed detector time-outs, creating blind spots. Pesek et al. [49] add that Internet service providers pay a high price to update collectors scattered across multi-vendor cores. Mapping such obstacles establishes realistic performance baselines and guides later design choices.

Speed, accuracy, and hardware ceilings pose the toughest technical hurdles. Bhattacharjee et al. [2] report that a NUMA-pinned software probe reached one hundred gigabits per second, yet lost 0.3% of packets during burst peaks. Sateesan et al. [9] match two-hundred-gigabit lines with FPGA meters but restrict each card to thirty-two megabytes of SRAM, which forces 1/256 sampling for long-tail flows. Gao et al. [10] note that INT in P4 switches adds 5.6/5 header overhead and caps export at ten gigabits per second on edge hardware. Lu et al. [57] halve memory with a two-layer sketch but accept plus-minus 1% counting error above forty million packets per second. Wrona et al. [5] warn that distributed IPFIX collectors consume twelve watts per one-hundred-gigabit link, raising data-centre power bills.

Operational and regulatory barriers are equally strict. Fejrskov et al. [8] needed General Data Protection Regulation audits before releasing DNS and SSH telemetry, delaying tests by months. Čeleda et al. [4] show that hashing only two of five IPv6 segments leaves some re-identification risk. Medeiros et al. [16] and Ndonda et al. [48] observe that half of the current studies label flows with a single intrusion-detection system, a practice that misses complex attack vectors. Four competing flow schemas further fragment benchmarks and hinder tool reuse.

Even so, several implementations deliver measurable gains. Pesek et al. [49] and Bhattacharjee et al. [2] keep packet loss below 0.1% at one-hundred-gigabit rates, trimming incident triage time by 30% in live trials. Li et al. [11] monitor fifty million packets per second on P4 switches with only two megabytes of SRAM, meeting campus cost targets. Campazas-Vega et al. [6] maintain overhead below 0.28% at a 1/1000 sampling rate, validating timeout tuning in production NetFlow. Wrona et al. [5] show that open-source exporters with reproducible build scripts speed up academic replication.

Common missteps persist. Campazas-Vega et al. [6] report that over-aggressive sampling cuts detection recall by 45% on encrypted traffic, while Jafarian et al. [14] note that single synthetic datasets limit ecological validity. Gao et al. [10] document switch queue drops when energy budgets ignore the overhead added by INT headers.

3.3. Methodological Quality of the Studies

The methodological quality of the 51 studies included in this review was assessed based on five domains, adapted by the author from the study by Kitchenham et al. [25]: clarity of context (D1), transparency of metrics (D2), validation process (D3), reproducibility (D4), and declaration of conflict of interest (D5). Each domain was scored from 0 (met) to 2 (not met), and the sum of the scores allowed the studies to be classified into three categories of methodological risk, as shown in

Table 5. Distribution of studies by level of methodological risk.

Risk Classification	Number of Studies	Percentage (%)
Low	17	33.3
Moderate	34	66.7
High	0	0.0

.

The scores per domain, as well as the individualized justifications for each study, are detailed in the adapted checklist, available in the full review protocol registered in the Open Science Framework (https://doi.org/10.17605/OSF.IO/MJ4XP (accessed on 14 September 2025)), as described in Section 2.5.

4. Discussion

Network-flow telemetry, that is, the practice of exporting compact records that describe each network connection, is now a key element of cyber defence. Our review clarifies how fifty-one peer-reviewed studies published from 2019 to July 2025 capture, transform, and use those records while facing rising speed, privacy, and regulatory demands. The evidence already shows a gap: throughput keeps growing faster than methodological standardisation, so high-speed probes still depend on ad hoc feature sets [2,47].

Regarding RQ1 and RQ2, we analyzed technology and validation. NetFlow (Cisco’s original five-tuple flow format) and IP Flow Information Export, or IPFIX, an extensible IETF standard, still dominate backbone networks because router firmware supports them. Authors now add loss-aware sampling and Non-Uniform Memory Access (NUMA) pinning to handle 100 Gbps traffic [1]. IPFIX accepts extra templates for Domain Name System (DNS) and Secure Shell (SSH), but needs more parsing time, whereas In-band Network Telemetry (INT), added inside programmable data planes, stamps each packet hop with latency at ten gigabits per second, increasing header size to gain precise path data [10]. CS-Sketch, a counting data structure stored inside the switch, compresses counters to fit static random-access memory (SRAM) and keeps heavy-hitter error below 1% at fifty million packets per second (Mpps) [11]. Validation mirrors these choices. Hardware collectors were tested on national backbones, while INT and sketch prototypes stayed in laboratory networks, which suggests a gradual shift from legacy exporters to programmable pipelines [49]. The combined evidence shows that accuracy, scalability, and latency improve through layered tweaks rather than a single replacement technology.

The evolution of flow-collection technologies reflects a trajectory shaped by the pursuit of greater scalability and precision. NetFlow, in its original five-tuple form, consolidated as the de facto standard due to its native integration into routers and the availability of mature tooling. IPFIX emerged as the IETF-standardized extension, allowing customizable fields but at a higher processing cost. Subsequently, techniques such as sFlow introduced header sampling to reduce export load, while more recent approaches such as INT/P4 and sketch-based collectors prioritize real-time telemetry and counter compression in programmable hardware. This trajectory indicates that, rather than direct substitutions, these technologies coexist to address different needs of precision, latency, and cost.

With respect to RQ3, studies report metrics inconsistently. Only one third kept the full 84 NetFlow fields, and most reduced them to twenty or forty attributes without explaining why, which hampers comparison [8,57]. Few papers measured energy cost or resilience to encryption, and only two reported watts per flow or detection rates on Transport Layer Security (TLS), traffic [5,45]. Question four revealed recurring privacy trade-offs. Hashing IPv6 addresses kept the subnet structure but still leaked parts of the host address, exposing regulatory gaps. Benchmark fragmentation also persists because four distinct flow schemas limit tool reuse and meta-analysis.

RQ4 revealed recurring privacy trade-offs. Despite these gaps, practitioners can apply several lessons. Routers sampling one of every one thousand flows kept overhead below 0.28% while detecting large attacks on production links [6]. Field-programmable gate array (FPGA) meters delivered sub-microsecond latency at two hundred gigabits per second, giving high-speed visibility for critical cores [9]. OpenFlow mirroring, which copies selected packets in Software-Defined Networking (SDN), isolates tenant traffic, although rule tables capped throughput at fifteen gigabits per second [39]. For policy makers, prefix-preserving hashing combined with on-site enrichment satisfied General Data Protection Regulation, GDPR, audits, but few studies measured re-identification risk, underscoring the need for standard test procedures.

Methodological strength varied. Our checklist, adapted from Kitchenham et al. [25], shows clear context descriptions but weak reproducibility, because fewer than ten papers published extraction code or labelled traces [15]. Many evaluations used only one synthetic dataset, which can inflate accuracy reports [16]. Even so, practices such as pilot calibration, dual reviewing, and transparent conflict statements raised confidence in the seventeen studies classed as low risk.

Future work should link telemetry to switch power budgets and publish watt-per-gigabit figures [50]. A benchmark backed by the community would let researchers compare flow schemas fairly and speed tool interoperability [59]. Privacy-preserving INT needs study, combining fast in-band telemetry with on-device anonymisation to meet latency and confidentiality goals [58]. Equally urgent is the release of open, carrier-grade datasets that capture encrypted traffic and new attack patterns.

One of the central findings of this review is the absence of a common evaluation framework. Studies report highly heterogeneous performance indicators, which hinder reproducibility and comparability across technologies. Establishing a concise set of shared benchmarks—covering accuracy, efficiency, robustness, and sustainability—would enable fairer assessments and stronger evidence for practical deployment. In addition, two dimensions stand out as underexplored yet critical for the maturity of flow collection: privacy and energy cost. While techniques such as prefix-preserving hashing have been tested to support compliance with privacy regulations, the actual risk of re-identification in encrypted traffic remains largely unmeasured. Similarly, only a minority of works quantify energy consumption (e.g., watts per gigabit), even as programmable pipelines and FPGA-based probes become widespread. Addressing these methodological gaps is essential to align flow collection research not only with technical requirements but also with ethical, regulatory, and environmental demands. In summary, exporter technology has advanced from software probes to hardware-assisted sketches, but shared methods lag behind. By mapping goals, exporter choices, extraction pipelines, and open challenges, this review offers a single reference for engineers and researchers. The next section turns these insights into practical recommendations and explains how coordinated standards can turn research progress into operational resilience [14,54].

5. Conclusions

This review answers its four research questions by quantifying how the community collects flow telemetry. NetFlow derivatives, which are Cisco’s original five-tuple flow records, appear in 62.7% of the fifty-one studies (RQ1). IP Flow Information Export (IPFIX), an IETF standard that allows custom fields, is used in 45.1%. In-band Network Telemetry (INT) written in the programmable language P4, or OpenFlow packet mirroring, is tested in 17.6%. sFlow, a packet-sampling method that exports only header snippets, is present in 9.8%. Researchers validate legacy exporters on high-speed backbone links, while they keep programmable sketches in laboratory testbeds (RQ2). Despite the variety of metrics, privacy controls, and energy reports, every paper aims to balance export accuracy with low detection latency (RQ3, RQ4) [2,10].

The synthesis links objectives, exporters, feature pipelines, and deployment evidence in one map. It updates the field with carrier-grade tests at one hundred gigabits per second and privacy-aware templates that earlier reviews did not cover. Unlike the sketch-focused survey by Lu et al., 2020 [57], our work shows that programmable data planes coexist with, rather than replace, traditional routers. We also describe the trade-off between larger packet headers and richer path visibility [4,49].

Practitioners can draw clear guidance. Router-embedded exporters with one-in-one-thousand sampling and adaptive timeouts keep overhead below 0.3% while still flagging large traffic floods [6]. Hardware probes accelerated by field-programmable gate arrays sustain two hundred gigabits per second and sub-microsecond latency, although each card needs thirty-two megabytes of static memory (SRAM). Prefix-preserving hashing of IPv6 addresses meets General Data Protection Regulation (GDPR) traceability rules when performed inside on-premise collectors, yet few studies measure the remaining risk of re-identification [33]. Successful deployments often rely on open-source toolchains that simplify tuning across devices from different vendors [5].

Looking forward, the next step is to apply the protocols and techniques identified in this review within the MICRA architecture [60], both in controlled testbeds and in operational environments. This will allow us to execute the machine-learning pipeline over real flow telemetry, compare exporter trade-offs in practice, and validate how privacy, energy efficiency, and detection accuracy interact under operational constraints. By grounding experimental evaluation in the systematic evidence collected here, we aim to consolidate MICRA as a flow-aware response framework capable of balancing scalability, resilience, and regulatory compliance.

This systematic review compiles nearly five years of evidence and shows how export pipelines, feature choices, and risk factors intertwine in cybersecurity telemetry. By highlighting strengths, gaps, and actionable priorities, it provides a roadmap for researchers, engineers, and regulators who aim to build flow-aware defences that match modern network threats. The flow-collection methods analyzed here are not merely technical choices for data export, but the foundation of cyber defence systems: their quality and efficiency determine the effectiveness of subsequent mechanisms such as intrusion detection, automated response, and forensic analysis. The trade-offs identified between speed, granularity, computational cost, privacy, and energy directly affect the resilience of organisations against contemporary cyber threats, making the evidence consolidated in this review a solid base for further research, better operational practices, and stronger cyber resilience.