I recently got a call from my friend Jack, who oversees his organization’s enterprise data center. His company has been a longtime Citrix customer and has used Citrix Application Delivery Management (ADM) to manage and monitor their applications and platforms.
He and his team upgraded to the latest version of Citrix ADM and are using Citrix Service Graph to manage and monitor microservices-based applications. He has liked the experience but has been puzzled at times by the different shades of the Citrix Service Graph. Sometimes Citrix Service Graph will only show a message that says No Services Found; sometimes the graph is partially connected; and sometimes some of the services don’t appear in the Citrix Service Graph.
He was trying to map names between the Citrix Service Graph nodes to service definitions deployed in the Kubernetes. Service definitions also include various labels associated with each service, and he was trying to see the labels in the Citrix Service Graph (the communication between two pods in Kubernetes and how it maps to the Citrix Service Graph). His asks were about connecting the dots between Kubernetes services deployed in a cluster and the Citrix Service Graph showing the services and the communication flows. So I gave Jack a Citrix Service Graph 101 overview, and I wanted to share here some of what I told him to help you get the most out of this powerful tool.
Sometimes Citrix Service Graph is partially connected. Why?
Citrix Service Graph’s nodes and edges are dependent on two data sources: Kubernetes’ service definition and Citrix ADC transaction logs. Kubernetes’ service definition is used to plot the nodes (vertex), and transaction logs are used to draw the edges (connect the nodes/vertex). A client request goes through many microservices before the client receives a response back, and Citrix ADC generates a transaction log whenever one service communicates with another via the Citrix ADC. Combined, these logs and service definitions from Kubernetes make the service graph.
Now, given the duration, all the services may not communicate with each other. In other words, if there are 30 services deployed in a Kubernetes cluster and in last hour only 10 are communicating, the Citrix Service Graph will show the communication flow of the 10 services. Other services will be depicted just as node, without any edge connecting to other nodes.
For example, as shown in the above diagram, the user can see only three services communicating with each other while three other services — redis-slave, redis-master-pods, lb-service-hotdrinks — are not. That’s why there are edges for the same.
How are the data for each node and edge classified, and why do they appear in red, orange, and green?
Citrix Service Graph collects the HTTP transactional log from Citrix ADC and monitors the response time and status codes. The data for each node and edge are classified in following ways:
Red (critical) — When an average service response time is greater than 200 milliseconds and the HTTP response error count is greater than zero for the selected duration (i.e. for the last hour).
Orange (review) — When an average service response time is greater than 200 milliseconds or the HTTP response error is greater than zero for the selected duration (i.e. for the last day).
Green (good) — When an average service response time is less than 200 milliseconds with no HTTP response errors for the selected duration (i.e. the last week).
As the image above shows, red indicates critical, orange shows review, and green signals good state. Users can filter the Citrix Service Graph using these filters, as well.
How do I correlate various performance metrics from one service to another?
Citrix Service Graph shows a tooltip when a user hovers over an edge or node. The tooltip contains an aggregation of performance metrics such as number of requests (hits), average service response time, number of HTTP response errors, and total volume of data. These collected metrics are computed using the sum and average for the selected interval (i.e. the last hour).
Sometimes I don’t see a graph, and there’s a message that says No Services Found.
By default, Citrix Service Graph queries for the last hour of data. If the query returns an empty dataset, the screen shows the No Services Found message. This indicates that in the last hour, Citrix ADC has not seen any traffic from any of the microservices deployed in the Kubernetes environment. However, the user can see any historical data using past interval or custom time.
The two Citrix Service Graph screenshots above show how a user can run into scenarios where the screen shows No Services Found. But if the user selects a longer duration, such as the last month, the Citrix Service Graph appears on the screen.
What have been the test environments for Citrix Service Graph?
We’ve tested Citrix Service Graph with open source Kubernetes, Calico (CNI), CPX (ADC Proxy) version 13.0-36.28, Citrix Ingress Controller version 1.1.3 deployed in Service Mesh lite with ADM Service, and Agent version 13.0 42.22.
Our pipeline includes many other flavors of Kubernetes like OpenShift, CNI, and Flannel, as well as various deployment modes including unified and two-tiered ingress, servicemesh, service mesh with Istio Gateway, and more.
Before you get started, make sure to check out the prerequisites for Citrix Service Graph.
