What is the significance of deploying third-party monitoring tools like Zabbix in AWS and GCP?

There are several advantages and disadvantages to deploying monitoring tools like Zabbix in an IaaS environment where existing monitoring tools exist.Let's list each of the following:

Vendors usually offer fewer monitoring items for easy deployment and may not be configured the way they want to be.
In that respect, deploying your own monitoring tools makes it easier to get what you want and compare their states.

@ As he pointed out, if you have an environment (called multi-cloud) for AWS and GCP, the monitoring tools provided by the vendor will depend on each tool.Therefore, you may not be able to get the same item, or you may not be able to get the item you want.And every time you increase your environment, you need to learn how to use it and set it up.On the other hand, third-party tools allow you to use them all over your environment once you have learned them.

Depending on the type and configuration of the monitoring tool, you will often have to set up separate instances and run them there, and take action if the monitoring tool suddenly dies.On the other hand, CloudWatch and StackDriver are managed services, so each vendor guarantees its operation.

Regardless of the tool, some knowledge is required from deployment to configuration to execution.In that respect, CloudWatch and StackDriver can almost automatically start monitoring.

CloudWatch can be configured with a few clicks to link with AWS SNS to notify you in case of an error.StackDriver is probably also possible.

To do the same with various monitoring tools, you may need to plug in AWS and write notification settings.

Specifically, I would like to monitor on Zabbix.Why don't you benchmark Cloudwatch by listing what you want to do?We don't know the monitoring requirements, but we don't know the advantages or disadvantages.On the other hand, if you say, "I don't know what you want to do, but I want to monitor it for now," you need to first organize the operational and non-functional requirements.
If you decide to do this and then say, "I want to do that and I want to do this," you have to make it twice or three times.

Now, the advantages that come to mind roughly based on the above assumptions and the points that make you want to use Zabbix are

• I would like to divert the definition of monitoring suppression and monitoring object used by existing on-premises systems.
  • Among the vast amount of information, "What to monitor and what to do with thresholds" is a rather complicated collection of know-how to design.
• I want to easily realize threshold monitoring, keyword monitoring, etc.
  • Didn't CloudWatch need to be implemented in Lambda?
• I want to use the system that I'm used to.
  • If you are currently using Zabbix, you will want to keep using it, leaving the know-how, device, and operating procedures intact.

• Among the vast amount of information, "What to monitor and what to do with thresholds" is a rather complicated collection of know-how to design.

• Didn't CloudWatch need to be implemented in Lambda?

• If you are currently using Zabbix, you will want to keep using it, leaving the know-how, device, and operating procedures intact.

"…I have noticed that ""server in AWS and GCP environment"" has been written so far…

For better or worse, CloudWatch is fine if you can "lock everything up in the same cloud," and it's useless to want to step outside.For example, use AWS as part of an existing system.If you use Zabbix & Cloud Watch, the cost will rise due to the complexity of the operation...Similarly, each monitoring system across AWS/GCP will not fool operational costs.Like preparing for each device...I think it's already Afo...
If so, using tools like Zabbix can be a very reasonable choice, regardless of the cloud you use.