Riverbed Performance Monitoring Reference
riverbed netprofiler appresponse cheatsheet
Architecture Overview
| Component | Product | Location | Data Type | Core Role |
|---|---|---|---|---|
| Portal | Riverbed Portal | EDC | None (UI only) | Central dashboard and navigation pane |
| Flow Gateway | Riverbed Flow Gateway | EDC | NetFlow/IPFIX/sFlow | Aggregates, deduplicates, and forwards flow records |
| NetProfiler | Riverbed NetProfiler | EDC | Processed flow records | Stores and analyzes flow history for all DCs |
| AppResponse (x5) | Riverbed AppResponse | EDC | Full packet captures (SPAN/TAP) | Transaction-level analysis, packet forensics |
| AppResponse (x4) | Riverbed AppResponse | RDC | Full packet captures (SPAN/TAP) | Same as above for RDC segments |
Data Flows
Flow-Based (NetProfiler)
Routers / Switches / Firewalls
|
export NetFlow/IPFIX
v
Flow Gateway (normalize, deduplicate)
v
NetProfiler (stores, correlates, queries)Packet-Based (AppResponse)
Switch SPAN/TAP
|
mirrored traffic
v
AppResponse appliances (DPI, transaction metrics, PCAPs)
v
Portal (dashboards only)Key Rule:
- Flows = centralized (EDC)
- Packets = distributed (EDC + RDC)
Metrics and Use Cases
| Category | Example Metrics | Where to View | Why / When You Use It |
|---|---|---|---|
| Application Performance (AppResponse) | App response time, server delay, client delay, RTT | Portal: App KPIs / AppResponse: Transaction Analysis | Validate app health, see where delay happens (network vs server vs client) |
| Transaction Stats (AppResponse) | HTTP/DNS/DB success/failure counts, response codes, query durations | Portal: App KPIs / AppResponse: Protocol-specific tabs | Correlate errors with deployments, find broken components |
| Network Health (AppResponse) | Retransmissions, packet loss, out-of-order, throughput, jitter | AppResponse: TCP Analysis | Prove or rule out network congestion, loss, or WAN instability |
| Conversation Summaries (AppResponse) | Top talkers, top servers, busiest apps by load | AppResponse: Conversations | Spot heavy hitters, isolate noisy clients or DDoS-like behavior |
| Flow Volumes (NetProfiler) | Bytes, packets, flows, conversations over time | NetProfiler: Traffic Summary / Host Pairs | Confirm who talked to who and how much, by time window |
| Flow Performance Metrics (NetProfiler) | RTT, retrans %, TCP setup failures, app ID by port | NetProfiler: Path Analysis / Application View | Baseline performance, find cross-DC latency, detect asymmetric routes |
| Alerts and Thresholds (both) | SLA violations, spikes, anomalies | Portal: Alerts / AppResponse: Thresholds / NetProfiler: Policies | Trigger proactive monitoring, feed NOC dashboards, auto ticketing |
Troubleshooting Workflow
General Rule: Start broad (NetProfiler for flows) then narrow down (AppResponse for packets).
Connectivity or Volume Issues
Goal: Did traffic even happen?
Tool: NetProfiler
Steps:
- Set time window (e.g., yesterday 14:00-15:00)
- Go Investigate > Traffic Summary or Host Pairs
- Filter by src/dst IP or subnet
- Look for bytes/flows, RTT, retrans %
- If no flows seen, check:
- Exporters sending NetFlow/IPFIX to Flow Gateway
- Flow Gateway forwarding to NetProfiler (TCP/41017 sessions alive)
- NetProfiler device inventory/API shows Flow Gateway online
Performance Issues (“It was slow”)
Goal: Why did traffic perform poorly?
Tool: NetProfiler then AppResponse
Steps:
- Use NetProfiler > Application View or Path Analysis
- Check RTT, retrans %, TCP setup success
- Identify the conversation (src/dst/port/time)
- Pivot into the correct AppResponse appliance (based on which DC saw it)
- In AppResponse > Transaction Analysis
- Check response time breakdown: client delay vs network vs server
- Look at retransmissions and errors
- Pull packet trace if needed
Impact Analysis (“Something broke after a change”)
Goal: Show before/after impact
Tool: AppResponse and NetProfiler
Steps:
- Compare traffic levels (NetProfiler) from before and after change
- Check AppResponse > HTTP/DNS/DB response codes and failures
- Check alert logs for SLA threshold hits during the change window
- Document server delay vs network delay deltas to show root cause
Flow Gateway Checks
| Check | How |
|---|---|
| Confirm it’s connected to NetProfiler | FG UI > Overview > NetProfiler Status |
| Confirm flows are arriving | FG UI > System > Information and Flow Stats |
| Confirm devices are exporting | NetProfiler > Administration > Flow Sources |
| Validate path | Ensure network devices > FG UDP/2055 and FG > NetProfiler TCP/41017 are allowed |
| FG not in Portal | Normal - FG is not an analysis data source |
Quick Mental Map
| Tool | Think of it as | Data Scope | When to Use |
|---|---|---|---|
| NetProfiler | ”Security cam footage” | High-level flow history (5-tuple) | Who/when/how much |
| AppResponse | ”Microscope” | Full packets | Why/how it behaved |
| Portal | ”TV news anchor” | No data, just dashboards | High-level triage, deep-links to others |
| Flow Gateway | ”Post office” | Passes flow mail to NetProfiler | Not for analysis, only flow transport |