Skip to main content

Observability User Guide

2.3. Get started using the Observability workflows

Once the configuration is complete, you can use the Observability workflows to visualize and analyze your metric data. cPacket drill-down workflows utilize services, locations, monitoring points, and protocols to logically organize your network and provide insights into its overall health and performance. Here are some examples to get you started.

2.3.1. Explore network performance using monitoring points

The Explore Monitoring Points workflow helps you identify potential issues by providing a view of the network traffic passing through your infrastructure. Was the session monitored between the firewall and the Internet or between the firewall and the Intranet? Each intermediary device or hop the data passes through could impact the overall network performance. By drilling down into these individual hops, you can identify where drops or latency issues occurred. To learn more, see About hop-by-hop analytics.

2.3.2. Search for a specific endpoint and investigate related metrics

On the Observability page, you can search for a slow server by IP address and then investigate its activity. Is the server overloaded, or did network latency affect the rate of data transfer? Drill down by peer IP addresses to see which clients or services the server interacted with and identify where drops occurred.Observability home page

2.3.3. Identify locations where latency is occurring

Monitor network performance in different parts of your network using the Location Latency workflow. Are latency issues isolated to a particular location, or are they widespread? Is network performance different across various locations, and where are the bottlenecks? Locations can be location-based, such as a data center, a POD, or a VPC. They can also be function-based, such as a pre-production environment, production environment, or testing environment.

2.3.4. Discover changes to your network by searching for protocols

Are there protocols running in your network that you don’t recognize? Which endpoints use these protocols? Use the Explore Protocols workflow to understand network applications running on your network, which are identified by their IP protocol and well-known TCP and UDP ports.

2.3.5. Investigate connection failures for a service

Is there a high rate of inbound connection failures? This could indicate the service is overloaded, misconfigured, or experiencing network issues. Are there a large number of SYN packets being received but a significantly smaller number of SYNACK packets being transmitted? This could indicate that the service is unable to keep up with the connection requests. Drill down into the peer IP addresses to see which clients or servers the service is interacting with. The Service Connection Failures workflow can help you answer these questions.

In this section:

A service is a user-defined group of endpoints and, optionally, specific ports that have a singular purpose in the network. This grouping can also be used to define subsets of the network that are managed by specific teams or groups, enabling clear ownership and responsibility.  To define Services, use the Services analytics label in the cClear UI.

A location is a user-defined group of endpoints that identify a physical location within your network topology. Locations can be nested, where one location is entirely contained within another, such as a data center rack, a hospital floor, or a specific building within a campus.  To define Locations, use the Locations analytics label in the cClear UI.

A monitoring point is the location in the network where the monitoring stack captures packets, typically a TAP, SPAN port, or remote SPAN such as ERSPAN, VXLAN, or GRE tunnel. Each monitoring point is uniquely identified by a combination of a cStor and a packet brokering port, such as 'Hoboken FW1 External'. Sources for this identifier include VLANs, cVu ports, or GENEVE VNI. To define monitoring points, use the Monitoring Points analytics label in the cClear UI.

A protocol is the combination of TCP or UDP and a port number used to identify a specific application, also known as a network application. For example, DNS uses port 53, and HTTPS uses port 443. To define protocols, use the Protocols analytics label in the cClear UI.