Kentik vs Flowtriq:
Observability vs Action

Back to Blog

We build Flowtriq. This post is not a general comparison of the two products (see the full comparison for that). This post focuses on a specific architectural difference, the gap between observability and action, and a new webhook integration that bridges it.

Kentik Sees Everything. Then What?

Kentik is a best-in-class network observability platform. It ingests flow data from across your network, correlates it with BGP routing tables, and provides deep visibility into traffic patterns, peering economics, and capacity utilization. Its DDoS detection module identifies attacks from aggregated flow data across your entire infrastructure. The visibility is real and valuable.

For mitigation, Kentik orchestrates external systems. It can trigger RTBH announcements via BGP to your routers. It can signal scrubbing centers through API integrations. It can fire webhooks to downstream systems. Kentik tells other systems to act. It does not act directly on the server under attack.

This is an architectural choice, not a flaw. Kentik is a network-level platform that sits above your infrastructure and looks down at aggregated flow data. It is not an agent running on individual servers. That network-level perspective gives Kentik visibility that per-server tools cannot match: cross-network attack correlation, traffic engineering insights, peering analysis. But it also means Kentik's mitigation options are limited to what it can instruct other systems to do.

Flowtriq runs on each server. It sees what each individual server sees, processes that data locally, and applies mitigation directly on the server's kernel. It does not have Kentik's network-wide visibility. It has per-server depth and local execution capability.

Observability vs Action

Kentik's strength is comprehensive network visibility. When an attack hits, Kentik shows you the attack profile: source distribution across ASNs, affected destination prefixes, protocol breakdown, volume trends over time. That visibility is genuinely useful for understanding what is happening and informing strategic decisions about network architecture and peering.

But visibility does not keep the server running.

When Kentik detects an attack, its automated response options are: trigger RTBH (server goes offline, attack and legitimate traffic both dropped), or signal a scrubbing center (minutes of activation time while traffic is rerouted through the scrubbing infrastructure, during which the attack continues hitting the target at full volume).

Flowtriq applies kernel-level firewall rules on the target server in 1-2 seconds. SYN cookies for SYN floods. Source rate limiting for amplification. Port drops for reflection. The server stays up for legitimate traffic while attack traffic is filtered. No RTBH, no scrubbing activation delay, no waiting for an external system to respond.

For a 500K PPS UDP flood, Kentik sees it across its flow data and can tell you exactly what ASNs the traffic originates from. Flowtriq sees it on the target server and stops it from causing damage. Both are valuable. They solve different parts of the problem.

The Webhook Bridge

Flowtriq now accepts Kentik alert webhooks directly at POST /api/v1/webhooks/kentik. This integration connects Kentik's network-level detection with Flowtriq's per-server mitigation.

The flow works like this: Kentik detects an attack from aggregated flow data and fires a webhook to Flowtriq. Flowtriq receives the webhook, maps the alert to the affected server, and creates a mitigation rule automatically based on the severity.

• Minor severity: Local rate limiting on the affected server. Kernel-level rules throttle suspicious traffic. Server stays fully operational.
• Major severity: FlowSpec rules pushed to the upstream router. Surgical filtering at the network edge. Server stays reachable.
• Critical severity: RTBH triggered as a last resort for link-saturating attacks that cannot be handled any other way.

The webhook bridge means Kentik's network-wide perspective informs Flowtriq's per-server response. Kentik sees the attack across the network. Flowtriq responds on the specific server being targeted. The detection comes from the best vantage point available, and the mitigation happens at the point where it can be most surgical.

See the integration guide for the full setup walkthrough, including webhook configuration, severity mapping, and escalation policy customization.

What Kentik Cannot See

Flow-based detection has inherent blind spots that come from how flow data is collected:

Sampling. Most flow export configurations use sampled flows (1:1000 or 1:2000 is common). A 50,000 PPS spike targeting a single server may produce only 25-50 flow records per export interval. In the context of millions of total flow records across a busy network, that signal can be difficult to distinguish from normal traffic variation. Kentik's detection algorithms are sophisticated, but they work with the data the flow export gives them.

Short-duration attacks. An attack lasting 15-20 seconds may end before enough flow samples accumulate for reliable detection. If the flow export interval is 30 seconds, the attack may not even appear in a complete export cycle. These short attacks are increasingly common, especially in gaming and competitive scenarios where the goal is a brief disruption, not sustained downtime.

Application-layer patterns. Flow data provides header-level information: source, destination, protocol, ports, byte counts, packet counts. It does not provide payload analysis. An HTTP flood that uses valid-looking requests at moderate per-source rates may not trigger flow-based anomaly detection because the per-flow characteristics look normal. Identifying these attacks requires packet-level inspection.

Flowtriq sees what each individual server sees, with no sampling. Every packet is visible to the agent. A 50,000 PPS spike on one server is immediately obvious. A 15-second attack is detected within the first 2 seconds. Application-layer patterns are visible because the agent has access to packet headers and connection state on the server.

This is not a criticism of Kentik's architecture. Flow-based, network-level analysis and per-server, packet-level analysis see different things. The strongest detection comes from having both perspectives.

The Complementary Architecture

The ideal architecture layers both perspectives:

Kentik at the network level: Network-wide observability. Traffic engineering and peering analysis. Capacity planning based on historical trends. DDoS detection across aggregated flow data. Cross-network attack correlation that identifies attacks spanning multiple targets. BGP route monitoring and anomaly detection.

Flowtriq on each server: Per-node DDoS detection with 1-2 second response time. Attack classification with confidence scoring. Automatic PCAP capture for forensic analysis. Kernel-level mitigation that keeps the server running. FlowSpec escalation when local filtering is insufficient. RTBH only as a last resort.

The integration: Kentik webhooks trigger Flowtriq for network-wide attacks that Kentik detects from flow data. Flowtriq handles server-specific attacks independently when the attack is too small or too brief for flow-based detection to catch. Together, there are no detection blind spots. Network-level events inform server-level responses. Server-level events are handled locally without waiting for network-level correlation.

Kentik tells you what is happening across your network. Flowtriq keeps each individual server running when an attack arrives. Both are doing what they do best.

For the Full Comparison

This post focuses on the observability-vs-action angle and the new webhook integration. For a detailed side-by-side covering features, pricing, deployment models, and architectural trade-offs, see the comprehensive Kentik vs Flowtriq comparison.