“Traceroute? You mean the thing I can type at the command line? Why would I even want to set up a test for that?”
This is, believe it or not, a comment we hear a lot at Catchpoint. At least from folks who are either new to tech, new to monitoring, or new to Catchpoint (or all three). It’s a common misconception.
It’s also something I’m not going to spend a ton of time addressing here. This blog is not meant to convince you why traceroute is super useful (even though it is). If you want more along those lines, I would like to suggest “How to Read a Traceroute”, which digs into both the history of the technology and the modern real-world use cases traceroute solves.
Instead, this guide is about one thing: giving you a jump-start to building your first (or even your next) traceroute test. It’s going to focus on the bare-minimum steps you need to get the job done, but I’ll also take some time to explore the other optional (but no less interesting) elements of a test.
Let’s get started.
Before you begin, make sure you have two things ready:
Friendly PSA: Your office printer is not a valid target. Unless you have that connected to the public Internet and OH FOR THE LOVE OF PANTS DON’T DO THAT. WHY WOULD YOU WANT TO DO THAT?!?
Ahem.
For more about Product and Folder locations, see here
Go into the Catchpoint portal and click "Control Center" from the left-hand navigation.
Select the Product or Folder (if you want. But if you don't pick now, you will be asked to select one after the next step)
Scroll down and you will see 5 options below "Traceroute".
These are:
If you're not sure which one you need, click each of the links above to see the differences.
Since you asked: Traceroute InSession is Catchpoint’s unique solution to several problems with “regular” traceroute. It’s a patented approach unique to Catchpoint. For more information about it, check out this article.
NOTE: DO NOT PANIC. You can change the test type later in this process, so don’t stress about locking it in just yet.
If you didn't select a Product or Folder before, you'll have to make a selection now.
That will open up your traceroute test properties screen.
The required elements for your test are:
Believe it or not, those are the only requirements for this test. There are, however, a bunch of other items you ought to fill in. Before I do, I’d like to direct your attention to the left-hand area of the screen:
Now, I know you’re probably not the person who deals with paying the bills at your company. But someone over there cares about how much things cost. That’s not to say Catchpoint requires a Brinks truck full of cash to operate. Quite the opposite. But folks in purchasing don’t like surprises, even if the “surprise” is that the cost doubled from $50 to $100. This is your chance to avoid getting an email from them asking questions.
Without getting too sidetracked, Catchpoint uses a point-based pricing model. Each test consumes a certain number of points depending on factors like:
For example:
Tip: There are dashboards that show the current consumption of points across your Catchpoint account, but it still pays (literally) to be aware of the relative cost of what you’re creating.
Some sections will be hidden unless you change this block from “Inherit” to something else. This is because – as the text implies – you’re inheriting those settings from the defaults (usually set at the “Property” level).
Here’s what each option does:
Easy-peasy, right? OK, let’s get back on track! There are a few elements that are required (marked with an asterisk) but you usually won’t need to deal with them.
They are:
Thresholds define when your test is considered to be in a Warning or Critical state. Here’s what to keep in mind:
These thresholds trigger visual indicators in dashboards and can be used to power alerts.
If you’re testing from multiple locations, Catchpoint gives you flexibility in how the test executes:
Alerts notify you when thresholds are crossed. In a basic setup, you can define:
NOTE: This is just the default setting for a basic alert. Catchpoint supports far more alert nuances than this but delving into it goes beyond the scope of this blog. We’ll dive deep into alerts in a future post.
If you’ve followed along until this point, you’ll have a functional traceroute test set up. Now you can click “Save” and bask in the warm glow of a job well done.
Now you can… uh… actually, what CAN you do now?
Obviously, the test is collecting data. But where is it? How can you see it? And – besides looking at it lovingly – what can you do with it?
One of the first ways to view the data from any test is using Smartboards
From within the test itself, you’ll see the Smartboard option at the top left corner.
But that’s not all. If you click the little down-y-arrow-thingy (Don’t laugh, this is a very technical term.) you’ll see some other options:
Performance
This is the default Smartboard view and includes:
Scatterplot
Think of this as the “Performance” option but without the connecting line. While traceroute might not generate the most thrilling graph you’ve ever seen, for other types of data it can be very informative.
You’ll see:
It's important to note that at the bottom of the graph area, somewhat hidden if you don’t know to look for it, is another section that’s worth your time. This area appears in other graphs, but I’m taking a moment to talk about it here.
You can expand this area by dragging up on the double-lines in the center. Depending on the type of graph you are showing, you’ll see tabs for a summary table, Errors, and Purge.
Summary Table provides a columns-and-rows view that shows:
Errors: As the name implies, this has details on the errors that have occurred with regard to this test.
Purge Summary: A list of any data that has been selected to be purged (a function covered elsewhere).
The Summary Table view gives you a compact, actionable snapshot of test behavior, errors, and cleanup history—making it easier to validate data or debug quickly.
Statistical view: The statistical chart view in Explorer provides you with 3 charts instead of one:
It’s worth noting that, like the Scatterplot graph, this Explorer has a Summary Table area at the bottom.
Records view: This option doesn’t open a new chart area but instead opens up a sub-panel showing the last few tests and their results (failure or success, and if successful, the test time). This is meant to be used for troubleshooting the test itself, either when you first create it or if it starts to have problems later on.
.png)
Together, the Statistical and Records views help you validate test stability and performance patterns over time. Use them to pinpoint trends, troubleshoot problems, and ensure your tests are running as expected.
While there’s a lot more to know about building dashboards in general, that topic is outside the scope of this blog. Trust that we will get to it in a future installment.
Not to sound like a broken reco… geeze that’s an old reference. Hmmm… Not to sound like the lowest Spotify plan? Nah. You know what? Go ahead and shoot me your best replacement for the “broken record” cliché in the comments.
But I digress. My point is that the process of building dashboards and alerts really is outside the scope of this blog. So, I will simply say that your new traceroute test would look great in a flashy new dashboard (or a hardworking old one). But getting it in there isn’t something we’ll be covering here.
Nor are we going to dive into all the amazing nuances of crafting a useful, informative, actionable alert. Not because you don’t need them, but because this blog is long enough as it is.
One of the immediate and obvious drawbacks to the “do it yourself” approach with traceroute is that you can only test from the point of view you have (meaning the system you’re currently on). This doesn’t come anywhere close to what anyone would consider comprehensive visibility.
In order for traceroute (or any monitoring test, really) to be effective, it needs to be run from multiple locations so that the true state of the target can be known. If a site shows down from Cleveland, but up from Bengaluru and Istanbul, then it’s not DOWN-down. It’s only down-ish (hey, I don’t make up these highly technical ter… Ok. I’m totally making them up. But I hope you go with it anyway. But I digress…)
For many monitoring tools, “multiple locations” is accomplished either by:
Catchpoint has 3,000 (that’s THREE-FREAKING-THOUSAND, for those who prefer their numbers in bold-underlined-all-caps) locations. Literally no other monitoring solution has that kind of coverage. And more than that, the locations are “real”. Meaning that they extend beyond just the usual suspects of cloud-and-colo. We have multiple endpoints embedded in every major ISP across the globe. And hundreds of “last mile” locations, which are as close to your house as we can get without having a device stuck in your underwear drawer.
This is such a critical difference that I thought it deserved its own section. And it applies not only to traceroute, but to every test in Catchpoint’s suite of solutions.
Yes! If there’s one thing you take away from this blog, it’s that setting up a traceroute test is both easy and impactful. Easy in the sense that there aren’t that many steps to get one stood up, and impactful because – as old… I mean “revered” as traceroute is, it still has a lot of relevance and importance in terms of helping you understand how your applications, networks, and infrastructure is performing.
Dive deeper
“Traceroute? You mean the thing I can type at the command line? Why would I even want to set up a test for that?”
This is, believe it or not, a comment we hear a lot at Catchpoint. At least from folks who are either new to tech, new to monitoring, or new to Catchpoint (or all three). It’s a common misconception.
It’s also something I’m not going to spend a ton of time addressing here. This blog is not meant to convince you why traceroute is super useful (even though it is). If you want more along those lines, I would like to suggest “How to Read a Traceroute”, which digs into both the history of the technology and the modern real-world use cases traceroute solves.
Instead, this guide is about one thing: giving you a jump-start to building your first (or even your next) traceroute test. It’s going to focus on the bare-minimum steps you need to get the job done, but I’ll also take some time to explore the other optional (but no less interesting) elements of a test.
Let’s get started.
Before you begin, make sure you have two things ready:
Friendly PSA: Your office printer is not a valid target. Unless you have that connected to the public Internet and OH FOR THE LOVE OF PANTS DON’T DO THAT. WHY WOULD YOU WANT TO DO THAT?!?
Ahem.
For more about Product and Folder locations, see here
Go into the Catchpoint portal and click "Control Center" from the left-hand navigation.
Select the Product or Folder (if you want. But if you don't pick now, you will be asked to select one after the next step)
Scroll down and you will see 5 options below "Traceroute".
These are:
If you're not sure which one you need, click each of the links above to see the differences.
Since you asked: Traceroute InSession is Catchpoint’s unique solution to several problems with “regular” traceroute. It’s a patented approach unique to Catchpoint. For more information about it, check out this article.
NOTE: DO NOT PANIC. You can change the test type later in this process, so don’t stress about locking it in just yet.
If you didn't select a Product or Folder before, you'll have to make a selection now.
That will open up your traceroute test properties screen.
The required elements for your test are:
Believe it or not, those are the only requirements for this test. There are, however, a bunch of other items you ought to fill in. Before I do, I’d like to direct your attention to the left-hand area of the screen:
Now, I know you’re probably not the person who deals with paying the bills at your company. But someone over there cares about how much things cost. That’s not to say Catchpoint requires a Brinks truck full of cash to operate. Quite the opposite. But folks in purchasing don’t like surprises, even if the “surprise” is that the cost doubled from $50 to $100. This is your chance to avoid getting an email from them asking questions.
Without getting too sidetracked, Catchpoint uses a point-based pricing model. Each test consumes a certain number of points depending on factors like:
For example:
Tip: There are dashboards that show the current consumption of points across your Catchpoint account, but it still pays (literally) to be aware of the relative cost of what you’re creating.
Some sections will be hidden unless you change this block from “Inherit” to something else. This is because – as the text implies – you’re inheriting those settings from the defaults (usually set at the “Property” level).
Here’s what each option does:
Easy-peasy, right? OK, let’s get back on track! There are a few elements that are required (marked with an asterisk) but you usually won’t need to deal with them.
They are:
Thresholds define when your test is considered to be in a Warning or Critical state. Here’s what to keep in mind:
These thresholds trigger visual indicators in dashboards and can be used to power alerts.
If you’re testing from multiple locations, Catchpoint gives you flexibility in how the test executes:
Alerts notify you when thresholds are crossed. In a basic setup, you can define:
NOTE: This is just the default setting for a basic alert. Catchpoint supports far more alert nuances than this but delving into it goes beyond the scope of this blog. We’ll dive deep into alerts in a future post.
If you’ve followed along until this point, you’ll have a functional traceroute test set up. Now you can click “Save” and bask in the warm glow of a job well done.
Now you can… uh… actually, what CAN you do now?
Obviously, the test is collecting data. But where is it? How can you see it? And – besides looking at it lovingly – what can you do with it?
One of the first ways to view the data from any test is using Smartboards
From within the test itself, you’ll see the Smartboard option at the top left corner.
But that’s not all. If you click the little down-y-arrow-thingy (Don’t laugh, this is a very technical term.) you’ll see some other options:
Performance
This is the default Smartboard view and includes:
Scatterplot
Think of this as the “Performance” option but without the connecting line. While traceroute might not generate the most thrilling graph you’ve ever seen, for other types of data it can be very informative.
You’ll see:
It's important to note that at the bottom of the graph area, somewhat hidden if you don’t know to look for it, is another section that’s worth your time. This area appears in other graphs, but I’m taking a moment to talk about it here.
You can expand this area by dragging up on the double-lines in the center. Depending on the type of graph you are showing, you’ll see tabs for a summary table, Errors, and Purge.
Summary Table provides a columns-and-rows view that shows:
Errors: As the name implies, this has details on the errors that have occurred with regard to this test.
Purge Summary: A list of any data that has been selected to be purged (a function covered elsewhere).
The Summary Table view gives you a compact, actionable snapshot of test behavior, errors, and cleanup history—making it easier to validate data or debug quickly.
Statistical view: The statistical chart view in Explorer provides you with 3 charts instead of one:
It’s worth noting that, like the Scatterplot graph, this Explorer has a Summary Table area at the bottom.
Records view: This option doesn’t open a new chart area but instead opens up a sub-panel showing the last few tests and their results (failure or success, and if successful, the test time). This is meant to be used for troubleshooting the test itself, either when you first create it or if it starts to have problems later on.
Together, the Statistical and Records views help you validate test stability and performance patterns over time. Use them to pinpoint trends, troubleshoot problems, and ensure your tests are running as expected.
While there’s a lot more to know about building dashboards in general, that topic is outside the scope of this blog. Trust that we will get to it in a future installment.
Not to sound like a broken reco… geeze that’s an old reference. Hmmm… Not to sound like the lowest Spotify plan? Nah. You know what? Go ahead and shoot me your best replacement for the “broken record” cliché in the comments.
But I digress. My point is that the process of building dashboards and alerts really is outside the scope of this blog. So, I will simply say that your new traceroute test would look great in a flashy new dashboard (or a hardworking old one). But getting it in there isn’t something we’ll be covering here.
Nor are we going to dive into all the amazing nuances of crafting a useful, informative, actionable alert. Not because you don’t need them, but because this blog is long enough as it is.
One of the immediate and obvious drawbacks to the “do it yourself” approach with traceroute is that you can only test from the point of view you have (meaning the system you’re currently on). This doesn’t come anywhere close to what anyone would consider comprehensive visibility.
In order for traceroute (or any monitoring test, really) to be effective, it needs to be run from multiple locations so that the true state of the target can be known. If a site shows down from Cleveland, but up from Bengaluru and Istanbul, then it’s not DOWN-down. It’s only down-ish (hey, I don’t make up these highly technical ter… Ok. I’m totally making them up. But I hope you go with it anyway. But I digress…)
For many monitoring tools, “multiple locations” is accomplished either by:
Catchpoint has 3,000 (that’s THREE-FREAKING-THOUSAND, for those who prefer their numbers in bold-underlined-all-caps) locations. Literally no other monitoring solution has that kind of coverage. And more than that, the locations are “real”. Meaning that they extend beyond just the usual suspects of cloud-and-colo. We have multiple endpoints embedded in every major ISP across the globe. And hundreds of “last mile” locations, which are as close to your house as we can get without having a device stuck in your underwear drawer.
This is such a critical difference that I thought it deserved its own section. And it applies not only to traceroute, but to every test in Catchpoint’s suite of solutions.
Yes! If there’s one thing you take away from this blog, it’s that setting up a traceroute test is both easy and impactful. Easy in the sense that there aren’t that many steps to get one stood up, and impactful because – as old… I mean “revered” as traceroute is, it still has a lot of relevance and importance in terms of helping you understand how your applications, networks, and infrastructure is performing.
Dive deeper
This is some text inside of a div block.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。