Forem: Piril Kavlak

API Monitoring Best Practices

Piril Kavlak — Mon, 05 Aug 2024 09:03:03 +0000

Application Programming Interfaces (APIs) are the foundation of modern inter-application communication. Their performance and availability directly impact end-user experience. Like other components of the application infrastructure, they must be monitored for availability, speed, error, and consistency.

This article covers the top best practices for effective API monitoring.

Best Practices for Effective API Monitoring

There are several key best practices for effective API monitoring that provide significant benefits:

1. Set Appropriate Key Performance Indicators

Clearly defining Key Performance Indicators (KPIs) or Service Level Objectives provides a benchmark to measure and understand API performance. Some common API performance metrics used as KPIs include:

Latency - the time to process a request
Response Time - the time to respond to a user request
Error Rate - the percentage of requests resulting in errors
Consistency/Accuracy - the predictability of system behavior
Availability - the uptime without disruptions
Throughput - the number of requests processed in a time frame

KPIs can also be customized to fit specific business needs. Once defined, KPIs enable creating Service Level Objectives (SLOs) which are performance targets for aspects of a system. SLOs facilitate Service Level Agreements (SLAs) between systems, especially with third-party vendors. SLAs can define compensation when agreements are not met.

Visualization of how a metric (KPI) can be used in conjunction with SLOs and SLAs

2. Continuous Real-Time Monitoring

APIs should be monitored 24/7 in real-time to detect anomalies and errors swiftly. Real-time monitoring enables a shorter mean time to recovery and reduces impact. Detecting issues early allows them to be addressed before evolving into larger problems affecting user experience, system performance, or data continuity.
Real-time monitoring is enabled by:

Services emitting logs and metrics while processing requests
Distributed tracing to track requests end-to-end
Emitting metrics and logs for 100% of traffic rather than samples

Endpoint level monitoring provides clearer understanding of bottlenecks or other issues. Solutions like Catchpoint gather metrics directly from user devices, tracing their internet journey for greater insight.

3. Set Up Alerts and Reporting

Alerts ensure teams are notified of problems needing attention. Metric and log-based alerts can trigger when values exceed thresholds. Alert configuration should balance avoiding noise fatigue and timely notifications. Reports help identify improvement opportunities and prove optimization successes.

Alert threshold chart

4. Integrate Monitoring with CI/CD Pipelines

Incorporating monitoring into continuous integration/continuous delivery (CI/CD) pipelines shifts monitoring left in the development process and bakes it in from the start. Pipelines can automatically generate and update dashboards so new metrics are covered when code reaches production.
Key aspects of pipeline integration include:

Validating data and SLOs by running pipeline tests against API endpoints using synthetic traffic to collect performance data
Identifying changes introduced across iterations
Enabling quick rollbacks when issues emerge

5. Understand the User Perspective

Monitoring user experience is critical for customer satisfaction, business performance, and product/service success. Synthetic monitoring emulates user transactions to measure workflow performance and detect issues proactively before users are impacted.
User perspective monitoring approaches include:

Simulating user requests from different regions and user types
Synthetic monitoring using scripts and real browsers to validate availability, performance, and functionality from an end user point of view
Promoting collaboration between technical and business teams to align monitoring priorities

As API endpoints serve end users, improving user experience based on monitoring data is key for positive outcomes. Frequently testing response data also builds perception of reliability and accuracy.

Conclusion

Effective API monitoring requires:

Customized KPIs tailored to business needs
Real-time monitoring to swiftly address issues
Actionable alerts balanced to notification needs
Integration with CI/CD pipelines for rapid iteration
Insights into user experience to guide improvements

By emphasizing these best practices, organizations can optimize API performance, and deliver a seamless and reliable user experience.

How to Read a Traceroute

Piril Kavlak — Mon, 03 Jun 2024 07:47:01 +0000

How to Run the Traceroute Command

Running a traceroute is very simple. The first step is to bring up a command prompt on your computer. The specific method will depend on your operating system. For Windows 10, for example, you can simply click on the start button and type CMD to bring up the options below.

Figure 1: Command Prompt options in Windows 10.

From here, simply click on the Command Prompt app to open it. When your command prompt has loaded, just type the command tracert followed by the destination you want to use to run the test. For example, to run a test to catchpoint.com, you would type tracert catchpoint.com and hit enter. (For Linux and macOS devices, you would type traceroute catchpoint.com instead.)

Available Options for the Traceroute Command

In most cases, the default traceroute command will give you the information you need. However, there are some additional options that you can use to get more details or change how the command runs. Accessing these options is done by adding one or more option flags after the traceroute command and before the destination.

How to Read the Results from a Traceroute

One of the best things about the traceroute tool is that once you learn how to read the results, you can understand the information it provides with just a quick glance. When you look at the example results of the traceroute listed above, you will see several key pieces of information.

The following table breaks down the key information you will see:

Hop Number

The first column just tells you which hop the trace is on. Whenever you access the Internet (or even data on an internal network), the data travels from one piece of hardware to another. These will typically be routers, but could also be switches, servers, or even computers. Each of these pieces of hardware that the data goes through is considered a hop.

Round Trip Time (RTT) Results

The next three columns show the amount of time it took data to go from the source (typically your computer) to that hop and back. This is measured in milliseconds.

Common Problems Discovered with Traceroute

You can use this command to look for various network issues and, based on the results displayed, determine what types of problems may be present.

Asterisks (Timeouts) at Various Points

The most common issue you will see with a traceroute is a timeout response, which is represented by an asterisk (*). These happen quite frequently and for a variety of different reasons. In the following example, you can see multiple hops have asterisks when attempting to run a traceroute to google.com.

C:\Users>tracert google.com
Tracing route to google.com [2607:f8b0:4009:819::200e]
Over a maximum of 30 hops:
1              1ms        1ms        1ms        2601:404:cf00:75c0:e2db:d1ff:fe1d:23ad
2              8ms        *             *             2001:558:4020:30::1
3              9ms        11ms     13ms     2001:558:112:3c0a::1
4              12ms     9ms        10ms     2001:558:110:b02c::1
5              *             20ms     *             2001:558:110:f1::1
6              34ms     20ms     27ms     2001:558:110:71::2
7              *             21ms     21ms     be-32131-cs03.350cermak.il.ibone.comcast.net [2001:558:3:2ae::1]
8              21ms     *             *             be-2311-pe11.350cermak.il.ibone.comcast.net [2001:558:3:72::2]
9              20ms     20ms     21ms     2001:559::11b2
10           19ms     20ms     20ms     2607:f8b0:831d::1
11           22ms     23ms     23ms     ord38s30-in-x0e.1e100.net [2607:f8b0:4009:819::200e]
Trace Complete
C:\Users>

Figure 2: Example output of traceroute to Google.

When you see an asterisk, it will mean one of the following things:

Single Asterisk on a Hop: This means that the request timed out on just one of the three attempts. This can be a sign that there is an intermittent problem at that hop.
Three Asterisks, Then Failure: If you see all three attempts at a hop have asterisks and then the traceroute errors out, it means that the hop is completely down.

Elevated Latency After One Hop

If everything looks fine for several hops, but then the response times jump up significantly at one point, and each hop after that remains high, it likely means a problem either at that hop or on the connection between it and the previous one.

Conclusion

The traceroute command is an essential tool for understanding the path your data takes across a network and for identifying connectivity issues along that path. By running traceroute tests to various destinations and analyzing the output, you can gain visibility into latency, loss, and other problems that may exist.

Key things to look for when interpreting traceroute results include asterisks indicating timed-out requests, sudden spikes in round-trip latency, and missing or unresponsive hops. These can help narrow down where an issue lies.

While traceroute has some limitations in very large or complex networks, it remains one of the simplest first steps in network troubleshooting. Understanding how to properly run the command, configure options like setting the maximum hops, and read the output is critical for anyone working with networks.

With a bit of practice reading traceroute results, the information it provides can save you substantial time getting to the root cause of connectivity and performance issues. It is a tool that should be in every network engineer's toolbox.

IP Multicast

Piril Kavlak — Fri, 31 May 2024 14:44:40 +0000

There are three different methods to deliver IP packets: unicast (one to one), broadcast (one to all), and multicast (one to many). Multicast sends packets only to destinations that have explicitly joined the multicast group. The routing devices replicate packets and forward copies to registered receivers while preventing routing loops. This article will cover multicast concepts like distribution trees, multicast addressing, forwarding, IGMP, and PIM.

IP Multicast Basics

IP Multicast has its own set of terms and concepts centered around the idea of a multicast group, which is a set of receivers interested in particular data. Hosts join groups using IGMP. The router's job is to build a distribution tree connecting receivers to sources. The interface towards the source is the upstream interface. The interfaces towards the receivers are downstream interfaces.

Multicast uses the Class D IP address range 224.0.0.0 to 239.255.255.255. The source IP is a unicast address, while the destination IP is a multicast address. At layer 2, multicast MAC addresses have the 25th bit set to 1. Multiple IP multicast addresses can map to the same MAC address.
The Class D range has reserved blocks:

224.0.0.0/24: Link Local
224.0.1.0 - 238.255.255.255: Globally Scoped
232.0.0.0/8: Source-Specific Multicast
233.0.0.0/8: GLOP Addresses
239.0.0.0/8: Limited Scope

Link local addresses are used by routing protocols and are never forwarded. IPv6 uses the ff00::/8 range with specific allocations like IPv4.

Multicast Distribution Trees

Distribution trees control the path multicast traffic takes through the network. The simplest is the Shortest Path Tree (SPT), which uses the shortest path between the source and receivers. The SPT is rooted at the source.
The SPT uses (S,G) state, where S is the source IP and G is the group address. Each source for a group has its own SPT. Below is an example SPT:

The second type of distribution tree is the shared tree, which uses a common root called the Rendezvous Point (RP). Source traffic goes to the RP over a source tree, then down the shared tree to receivers. The shared tree uses (*,G) state since all sources use the shared infrastructure.

The advantage of SPTs is optimal paths, while shared trees require less state. However, shared tree latency can be higher.

Multicast Forwarding

In multicast forwarding, the source sends traffic to a group of hosts. Routers track incoming and outgoing interfaces. They use Reverse Path Forwarding (RPF) to forward traffic away from the source to prevent loops.
RPF relies on the unicast routing table to determine upstream and downstream neighbors. A router forwards a multicast packet only if it arrives on the upstream interface. This check ensures delivery along a loop-free tree. Traffic passing the RPF check is forwarded, else it is dropped.
The RPF check logic:

Check if the source is reachable via the input interface per the routing table
If yes, traffic passes the RPF check and is forwarded
If no, traffic fails the RPF check and is dropped

IGMP

The Internet Group Management Protocol (IGMP) handles hosts joining multicast groups on a LAN. Routers use IGMP to learn group membership:

Querier routers send queries to see if hosts want traffic
Hosts send reports to confirm interest IGMPv2 added a Leave Group message to reduce unwanted traffic. IGMPv3 supports source-specific groups and source filtering.

Conclusion

IP multicast provides an efficient one-to-many transport model. Core concepts include multicast addressing, distribution trees, multicast forwarding with RPF checks, and IGMP for group management.
Multicast routing protocols like PIM build distribution trees between senders and receivers:

PIM Dense Mode floods traffic then prunes branches
PIM Sparse Mode starts with no flow and then builds shared trees

Multicast technologies enable scalable services like high-definition video streaming and software updates. Understanding the core concepts allows network engineers to effectively design, implement, and troubleshoot multicast networks.

This concludes our overview of IP multicast. The article covered addressing, forwarding, IGMP, distribution trees, and routing protocols. With this foundation, you can now configure and manage multicast services on real-world networks.