I'm curious if anyone has experience with pushing Citrix AppFlow data to DCRUM. It appears to map directly to Cisco Netflow protocols with are supported to AMD Netflow collector.
From the Citrix docs:
The Citrix® NetScaler® appliance is a central point of control for all application traffic in the data center. It collects flow and user-session level information valuable for application performance monitoring, analytics, and business intelligence applications. AppFlow transmits this information by using the Internet Protocol Flow Information eXport (IPFIX) format, which is an IETF standard defined in RFC 5101. IPFIX (the standardized version of Cisco's NetFlow) is widely used to monitor network flow information. AppFlow defines new Information Elements to represent application-level information.
Using UDP as the transport protocol, AppFlow transmits the collected data, called flow records, to one or more IPv4 collectors. The collectors aggregate the flow records and generate real-time or historical reports.
AppFlow provides visibility at the transaction level for HTTP, SSL, TCP, and SSL_TCP flows. You can sample and filter the flow types that you want to monitor. AppFlow use actions and policies to send records for a selected flow to specific set of collectors. An AppFlow action specifies which set of collectors will receive the AppFlow records. Policies, which are based on advanced expressions can be configured to select flows for which flow records will be sent to the collectors specified by the associated AppFlow action.
I'd like to know how this data could best be utilized. It seems that there is application logic and possible timing details contained in these records, are these details complimentary and useful to augment RUM data in any way, or possibly even better in the case where no data feed is possible to AMD for whatever reason (unsupported ciphers, excess duplicate packets, etc)? Can AMD use the application data, or is Netflow data to AMD only applicable in the context of network devices?
Solved! Go to Solution.
Augmenting Citrix data with AppFlow records is one specific use case, but there are much larger considerations. Our organization (and countless others in heavily regulated industries) are being pushed for rapid adoption and full deployment of EC ciphers which render all SSL communications packet contents invisible to AMD. The ability to mine the entire AppFlow record set as a data source/AMD replacement could help keep DCRUM a relevant APM player in this space. Other solutions may be in the works as well, but this is definitely a change that is poised to dramatically change the value statement of DCRUM at our shop in the coming months.
EC and DH and all the other non support ciphers all pose the same problem (and it's not new if anyone ever thought so). The question you ALWAYS should ask is - "How will you be able to see what traffic is in your network. How will you be able to backtrack problems and breaches. Explain to me how this will support the need for traceability"
Also bring the same questions up with the IT Security people. Ask them if they ever had a breach and what they did then. If someone hacks a server or a database, I guarentee that they will also erase logs and records of their breach, leaving you to look at the network - where you now would be blind if you go all in with DH&EC.
Most sensible IT Sec people will understand that obscuring (encrypting) to the max is not the best solution and are open to discussion for other approaches.
That said, many times I've seen customers using several layers of encryption on a single transaction which from a performance perspective is less wise as it increases the processing overhead and reduces the room for payload (Ooh - why do I transmit packets in the first place, wasn't it so that I can use all the fancy encryption?) and complicates management of the infrastructure.
Sensible encryption is to encrypt (using whatever technique you want) when data leaves your Control zone, such as DC, LAN/WAN or simply a building.