As more and more organisations take what is optimistically called "transformation" journeys the complexity of the IT landscape inevitably increases. I'm not for one moment suggesting that "transformation" is a one-word summary for "move to a cloud", but there will inevitably be a cloudy discussion at some point.
I have heard arguments that say "the reason we use cloud is so that we can just consume IT and not have to support it. If it breaks, it's not us who fixes it." or occasionally I've heard "we sign up for delivery of a service, we've got an SLA. No service, no pay. So I've ring-fenced my responsibility."
Both of which are, frankly, only ever spoken by accountants. They do have a point, it's just the point they make is the wrong point.
At the time of writing, AWS offers over 200 IT services on its AWS platform (https://aws.amazon.com/product... ). It's a million miles away from the old days of EC2, S3 and a database.
You might decide that your first tender foray into cloud is to migrate wholesale your current server, databases and applications to cloud. Known as "lift and shift". The next step is to re-factor those systems into more cloud-native functionality using, e.g. Lambda functions (forgive the AWS references, it's my "cloud du jour" at the moment).
So you have a transition in place where you, as a head of IT, are responsible for an unholy combination of on-premises services and cloud-based services. And, the bad news is that's not going away anytime soon.
You still have to deliver an IT service to your customers. Cloud introduces a middleman into that delivery flow. Definitely an important middleman though, with theoretically more resilient data centres, unlimited capacity and physical security.
As business services are created from combinations of cloud providers, 3rd party providers (e.g. for payment API's), on-premise systems and external contributors it quite simply means that you actually need more monitoring.
To counter the accountants argument, i.e. "It's not my problem I've got an SLA". Then without monitoring, how would you know which supplier and which SLA is in jeopardy?
We must therefore accept that cloud monitoring is as important - if not more important - than conventional monitoring. It then follows that the monitoring solution you choose must be able to gather, process and interpret monitoring data from just about anywhere and anytime and present it to you in a meaningful way.
For cloud specific monitoring, my simple advice is don't work in isolation.
Don't monitor cloud in isolation.
Don't accept that vendor solutions are the only solutions.
Monitor the service you are providing as an entity in its own right, not using 15 different monitoring tools. If you don't then all you will acheive is a worn out office carpet and a need for new wheels on your office chair as you switch between banks of monitors looking for the cause of the problem.
If your approach is to go for what you believe to be "best-of-breed monitoring" for each and every component of your IT landscape, then expect to spend a lot on office carpet.
"Yes but we can integrate the best-of-breed tools into a manager of managers" I hear you say. Yes, indeed you can. But then your monitoring is only as good as your integrations and unless they all use a common API and, to a certain degree, a common data structure, then you will inevitably lose something in translation.
My advice, if you're a technical person is to not consider cloud monitoring in isolation. Technically, consider how rich a set of data ingestion functions your monitoring software has. How extensible is the monitoring agent? Can I use older standards for data collections (SNMP, WMI etc) ?
Your cloud provider will (should) provide a rich set of monitoring metrics via their proprietary monitoring services, e.g. AWS Cloudwatch. But don't rely on Cloudwatch in isolation. Feed your cloudwatch metrics into your monitoring tool and consolidate not at the tool level but at the data level.
Now for the declaration bit : I am a director of Nobius, a UK-based IT Monitoring business specialising in Zabbix.
Zabbix has been around for many many years and is totally open-source. Yes, you can inspect the source-code, change the source-code even. As the source code is freely available it can be forensically examined for security issues. Nothing is hidden.
Zabbix has massive scalability and variety of data ingestion mechanisms including cloud-native API's, IPMI, SNMP, Log Files, WMI, scripts - the list goes on.
Zabbix is either agent-based or agentless - or both at the same time giving flexibility for data ingestion.
Summary
The benefits of cloud-monitoring are probably more than the sum of their parts;
1. Knowing where in your archiecture a problem lies - cloud, network, on-premise, application code. It's not just about cloud monitoring. The cloud is only a part of your solution
2. Knowing which SLA to wave at your supplier is important. Work collaboratively and complain with confidence if the supplier is contributing to service failures.
3. Comparison of cloud monitoring tools isn't a great way to make a decision on monitoring.
4. Choose a solution that meets the widest range of data ingestion mechanisms possible. After all, if you can't get the data you can't do the monitoring.
Cloud Monitoring Software is designed to track and manage the operational status, health, and performance of cloud-based applications, services, and infrastructures.
AWS Cloud Watch, Datadog, Sumologic
Thanks for the recommendations! Can you share some insight into the benefits of cloud monitoring, and of these particular tools?
Hi,
As more and more organisations take what is optimistically called "transformation" journeys the complexity of the IT landscape inevitably increases. I'm not for one moment suggesting that "transformation" is a one-word summary for "move to a cloud", but there will inevitably be a cloudy discussion at some point.
I have heard arguments that say "the reason we use cloud is so that we can just consume IT and not have to support it. If it breaks, it's not us who fixes it." or occasionally I've heard "we sign up for delivery of a service, we've got an SLA. No service, no pay. So I've ring-fenced my responsibility."
Both of which are, frankly, only ever spoken by accountants. They do have a point, it's just the point they make is the wrong point.
At the time of writing, AWS offers over 200 IT services on its AWS platform (https://aws.amazon.com/product... ). It's a million miles away from the old days of EC2, S3 and a database.
You might decide that your first tender foray into cloud is to migrate wholesale your current server, databases and applications to cloud. Known as "lift and shift". The next step is to re-factor those systems into more cloud-native functionality using, e.g. Lambda functions (forgive the AWS references, it's my "cloud du jour" at the moment).
So you have a transition in place where you, as a head of IT, are responsible for an unholy combination of on-premises services and cloud-based services. And, the bad news is that's not going away anytime soon.
You still have to deliver an IT service to your customers. Cloud introduces a middleman into that delivery flow. Definitely an important middleman though, with theoretically more resilient data centres, unlimited capacity and physical security.
As business services are created from combinations of cloud providers, 3rd party providers (e.g. for payment API's), on-premise systems and external contributors it quite simply means that you actually need more monitoring.
To counter the accountants argument, i.e. "It's not my problem I've got an SLA". Then without monitoring, how would you know which supplier and which SLA is in jeopardy?
We must therefore accept that cloud monitoring is as important - if not more important - than conventional monitoring. It then follows that the monitoring solution you choose must be able to gather, process and interpret monitoring data from just about anywhere and anytime and present it to you in a meaningful way.
For cloud specific monitoring, my simple advice is don't work in isolation.
Don't monitor cloud in isolation.
Don't accept that vendor solutions are the only solutions.
Monitor the service you are providing as an entity in its own right, not using 15 different monitoring tools. If you don't then all you will acheive is a worn out office carpet and a need for new wheels on your office chair as you switch between banks of monitors looking for the cause of the problem.
If your approach is to go for what you believe to be "best-of-breed monitoring" for each and every component of your IT landscape, then expect to spend a lot on office carpet.
"Yes but we can integrate the best-of-breed tools into a manager of managers" I hear you say. Yes, indeed you can. But then your monitoring is only as good as your integrations and unless they all use a common API and, to a certain degree, a common data structure, then you will inevitably lose something in translation.
My advice, if you're a technical person is to not consider cloud monitoring in isolation. Technically, consider how rich a set of data ingestion functions your monitoring software has. How extensible is the monitoring agent? Can I use older standards for data collections (SNMP, WMI etc) ?
Your cloud provider will (should) provide a rich set of monitoring metrics via their proprietary monitoring services, e.g. AWS Cloudwatch. But don't rely on Cloudwatch in isolation. Feed your cloudwatch metrics into your monitoring tool and consolidate not at the tool level but at the data level.
Now for the declaration bit : I am a director of Nobius, a UK-based IT Monitoring business specialising in Zabbix.
Zabbix has been around for many many years and is totally open-source. Yes, you can inspect the source-code, change the source-code even. As the source code is freely available it can be forensically examined for security issues. Nothing is hidden.
Zabbix has massive scalability and variety of data ingestion mechanisms including cloud-native API's, IPMI, SNMP, Log Files, WMI, scripts - the list goes on.
Zabbix is either agent-based or agentless - or both at the same time giving flexibility for data ingestion.
Summary
The benefits of cloud-monitoring are probably more than the sum of their parts;
1. Knowing where in your archiecture a problem lies - cloud, network, on-premise, application code. It's not just about cloud monitoring. The cloud is only a part of your solution
2. Knowing which SLA to wave at your supplier is important. Work collaboratively and complain with confidence if the supplier is contributing to service failures.
3. Comparison of cloud monitoring tools isn't a great way to make a decision on monitoring.
4. Choose a solution that meets the widest range of data ingestion mechanisms possible. After all, if you can't get the data you can't do the monitoring.
David Collier
Nobius
Hi, I recommend this article to you by clicking on this link.
it can better orient you on the questions you are asking yourself.
Good reading.
https://phoenixnap.com/blog/cl...