I'll start this, the third and final entry in my series on APM and Observability, which was originally inspired by my contribution to an APMdigest article, by once again pointing out that APM tools can be built with observability in mind. Many are, in fact. And the ones that aren’t don’t turn into a different type of tool. In my experience, it's more that there's a difference of mindset.
Once again I want to caveat my delineation between “APM” and “Observability” by saying
For reference (and to save you re-reading two other blog posts):
.jpg)
Imagine you have a specific problem in front of you. After research and analysis, you come to the conclusion that you need a new tool to solve this problem. If the tool you pick is APM, it means you had one type of mindset about your problem (and your needs, and the specific context, etc.). If, on the other hand, an observability-centric solution is what you selected, then you had a different mindset.
If you decided to solve the problem with a typical APM tool, it means you were focused requesting status of the component elements as needed, with less emphasis on what was happening under the hood. The data collected is more centered on when application had an issue, and what the experience of that impact was – not what line of code or sub-system failed, but how that issue bubbled up and manifested in terms of user experience. Only after those questions are answered would additional insight into the technical aspects be included.
That's not to say that APM tools don't test or look at sub-components of a website. As I called out in part 6 of the APMdigest series, “Modern, robust APM tools can test everything from individual database queries to API calls and beyond. It's just that the focus is on how those elements are experienced from an external point of view, rather than how it works from inside the application (or website, or whatever) itself.”
.jpg)
Continuing along that line of thinking from the APMdigest article: “On the other side of the fence, if your decision was to address the imaginary issue with a solution that was observability-centric, it would indicate that your first concern was from an inside-the-code perspective; and that you were worried not so much about predictable ways the application (or website, or whatever) could fail, but rather on all the unpredictable things that might happen down the road. The so-called "black swan" events.”
Do organizations need both APM and observability tools, or can they get everything in one tool?
While it's possible for APM tools to have an observability-focused design and feature set, providing a best-of-both-worlds experience, most don't. In part 8 of the APMdigest series I pointed out, “And even the solutions that are a blend of both worlds — usually the result of acquired companies and merged toolsets — end up focusing on more of one than the other, with the lesser of the two simply there to provide context to the other or, worse, to be little more than box-checkers to pass an RFP.
So, putting aside my pedantic philosophizing, yes, companies will probably need both. More specifically, different teams within an organization will require the capabilities of one more than the other.”
Driving deeper into the meat of the issue, it becomes clear that APM and observability tools are used by different roles. Furthermore, the selection of the solution will largely depend on the types of problems that the role most often needs to fix. For roles and teams where the critical piece is knowing when something (an application, website, or other system) starts failing, and the points at which (from the user's perspective) the failure manifests, APM tools are the preferred choice. This extends to major subcomponents, such as databases and APIs, and even to significant dependencies, like DNS.
Meanwhile, if the role/team's focus is on the internals — code execution and log messages — then so-called "observability tools" would be the preferred option.
Compare what you can monitor with APM vs IPM
APM and observability serve distinct but complementary roles in modern monitoring. APM focuses on tracking and alerting for known issues in a system, providing visibility into how problems impact the user’s experience and pinpointing where things go wrong. Observability, on the other hand, empowers teams to dive deeper into unknown or complex issues by helping uncover the “why” behind failures. Modern organizations benefit most by using both approaches, selecting the right tool, and the right mindset, for each challenge they face
I'll start this, the third and final entry in my series on APM and Observability, which was originally inspired by my contribution to an APMdigest article, by once again pointing out that APM tools can be built with observability in mind. Many are, in fact. And the ones that aren’t don’t turn into a different type of tool. In my experience, it's more that there's a difference of mindset.
Once again I want to caveat my delineation between “APM” and “Observability” by saying
For reference (and to save you re-reading two other blog posts):
Imagine you have a specific problem in front of you. After research and analysis, you come to the conclusion that you need a new tool to solve this problem. If the tool you pick is APM, it means you had one type of mindset about your problem (and your needs, and the specific context, etc.). If, on the other hand, an observability-centric solution is what you selected, then you had a different mindset.
If you decided to solve the problem with a typical APM tool, it means you were focused requesting status of the component elements as needed, with less emphasis on what was happening under the hood. The data collected is more centered on when application had an issue, and what the experience of that impact was – not what line of code or sub-system failed, but how that issue bubbled up and manifested in terms of user experience. Only after those questions are answered would additional insight into the technical aspects be included.
That's not to say that APM tools don't test or look at sub-components of a website. As I called out in part 6 of the APMdigest series, “Modern, robust APM tools can test everything from individual database queries to API calls and beyond. It's just that the focus is on how those elements are experienced from an external point of view, rather than how it works from inside the application (or website, or whatever) itself.”
Continuing along that line of thinking from the APMdigest article: “On the other side of the fence, if your decision was to address the imaginary issue with a solution that was observability-centric, it would indicate that your first concern was from an inside-the-code perspective; and that you were worried not so much about predictable ways the application (or website, or whatever) could fail, but rather on all the unpredictable things that might happen down the road. The so-called "black swan" events.”
Do organizations need both APM and observability tools, or can they get everything in one tool?
While it's possible for APM tools to have an observability-focused design and feature set, providing a best-of-both-worlds experience, most don't. In part 8 of the APMdigest series I pointed out, “And even the solutions that are a blend of both worlds — usually the result of acquired companies and merged toolsets — end up focusing on more of one than the other, with the lesser of the two simply there to provide context to the other or, worse, to be little more than box-checkers to pass an RFP.
So, putting aside my pedantic philosophizing, yes, companies will probably need both. More specifically, different teams within an organization will require the capabilities of one more than the other.”
Driving deeper into the meat of the issue, it becomes clear that APM and observability tools are used by different roles. Furthermore, the selection of the solution will largely depend on the types of problems that the role most often needs to fix. For roles and teams where the critical piece is knowing when something (an application, website, or other system) starts failing, and the points at which (from the user's perspective) the failure manifests, APM tools are the preferred choice. This extends to major subcomponents, such as databases and APIs, and even to significant dependencies, like DNS.
Meanwhile, if the role/team's focus is on the internals — code execution and log messages — then so-called "observability tools" would be the preferred option.
Compare what you can monitor with APM vs IPM
This is some text inside of a div block.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。