These are valid points. But I think people pay third-party monitoring for convenience and productivity more than need.
In reality, most dev teams don't have time (or prefer not to spend time) configuring all monitoring rules & metrics. For most apps, what needs to be monitored doesn't really change much.
A big issue with CloudWatch Logs is debugging. It's a pain. Especially if you have a high-throughput and high-concurrency Lambda. Logs are scattered across various streams, which are linked to each Lambda microVM lifecycle (start/end independently). Inside each Stream, it's visually hard to spot where an invocation starts and ends. X-Ray traces and CW Logs aren't visually integrated as well. The lack of a good developer experience is what drives people to pay for a well-crafted UI and more integrated (data-wise) environment.
Apologies for the late reply. All true, there is a target market for both native and third party monitoring. I get what you are saying about CW Logs, I have been using it for years now and have probably grown accustomed to it. I do see new developers in the space struggle for a while before also accepting how CW Logs work.
CW Log Insights on the other hand provides a lot of functionality and helpful queries, some that aren't available in third party monitoring last I checked.
CW Logs Insights has lots of functional limitations (ie. what it CAN do, not considering DX issues like the query syntax being too verbose for searching string fragments) and is not sufficient for a lot of people's needs, e.g.
you're limited to 20 log groups at a time, so you need to know roughly what you're looking for to begin with
you can only search logs for functions in one region and one account, many orgs run multiple accounts (in fact, this is AWS's recommended practice) and need a log aggregation platform that aggregates everything, CW Logs can't do that at the moment
The same goes to all the other services, in general, they're good enough when you're starting out but most people grow out of them and need something more capable. X-Ray for example, has poor support for async event sources (only SNS is supported right now), so if you have an event-driven architecture it's of very limited use.
These limits are indeed a pain. It would be relatively simple to deploy a Lambda with logic to overcome the Log Group and Region limitations. But then the team would start deviating from the core business. In most enterprise projects it will make more sense to pay someone that can do it well.
AWS is focused on providing infrastructure. CW handles the infra really well for collecting and storing logs. Swifting through and analyzing them is another business, from my point of view...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
These are valid points. But I think people pay third-party monitoring for convenience and productivity more than need.
In reality, most dev teams don't have time (or prefer not to spend time) configuring all monitoring rules & metrics. For most apps, what needs to be monitored doesn't really change much.
A big issue with CloudWatch Logs is debugging. It's a pain. Especially if you have a high-throughput and high-concurrency Lambda. Logs are scattered across various streams, which are linked to each Lambda microVM lifecycle (start/end independently). Inside each Stream, it's visually hard to spot where an invocation starts and ends. X-Ray traces and CW Logs aren't visually integrated as well. The lack of a good developer experience is what drives people to pay for a well-crafted UI and more integrated (data-wise) environment.
Apologies for the late reply. All true, there is a target market for both native and third party monitoring. I get what you are saying about CW Logs, I have been using it for years now and have probably grown accustomed to it. I do see new developers in the space struggle for a while before also accepting how CW Logs work.
CW Log Insights on the other hand provides a lot of functionality and helpful queries, some that aren't available in third party monitoring last I checked.
Insights is indeed very powerful, it was a great feature added by the CW Logs team.
CW Logs Insights has lots of functional limitations (ie. what it CAN do, not considering DX issues like the query syntax being too verbose for searching string fragments) and is not sufficient for a lot of people's needs, e.g.
The same goes to all the other services, in general, they're good enough when you're starting out but most people grow out of them and need something more capable. X-Ray for example, has poor support for async event sources (only SNS is supported right now), so if you have an event-driven architecture it's of very limited use.
These limits are indeed a pain. It would be relatively simple to deploy a Lambda with logic to overcome the Log Group and Region limitations. But then the team would start deviating from the core business. In most enterprise projects it will make more sense to pay someone that can do it well.
AWS is focused on providing infrastructure. CW handles the infra really well for collecting and storing logs. Swifting through and analyzing them is another business, from my point of view...