With the advent of the cloud, managed services, IaaS and PaaS, our packages are no longer self-sufficient and each infrastructure uses its own orchestration processes for the deployment of new servers (VMs or containers).

If this is your case then this article is for you, you will discover how to configure our agents using your orchestrators.

Standard installation procedure

In order to understand the rest you will find the standard installation guide of our agent is here:

Install system agents

And the installation guide of our PHP module (if you use this technology) here:

Install the PHP / Magento / OroCommerce profiler

Dynamization for the cloud

In the case of automatic or semi-automatic deployment of instances (VM or containers) some configuration fields will have to be modified or replicated between each newly created instance:

• Token: The identification token must be the same for all Quanta agents of the same license and site, this is found in the configuration file "/etc/quanta/agent.yml". The token tells the agent which site the monitored data belongs to.
• Hostid: This is also found in the configuration file "/etc/quanta/agent.yml". The hostid is a unique identifier that allows Quanta to uniquely identify an instance:
  • In the vast majority of cases the hostid must be different for each new instance, so your new "front-nginx-3" instance will not try to overwrite the data sent by the "front-nginx-2" instance.
  • In the case of auto-scaling you may need to keep a unique identifier when an instance is deleted and later recreated. For example if every evening around 7pm you add a fourth front to handle the early evening load and delete it around 9pm you might want to avoid having a new graph appear in your Quanta data every day (and end up with a very long list of graphs). In this case you will have to keep a unique identifier each time you delete and re-create the front in question, so the data will always appear in the same graph.
• Hostname: Still in the same file "/etc/quanta/agent.yml", this configuration variable allows you to assign a label to your instance, unlike the hostid it is not an identifier but only a name to make it easier to read in the graphs, for example "VM prod 006 - Varnish - 3". You can also modify it from the QUANTA interface.

Adaptation

Some cloud providers offer managed services, AWS offers RDS and ElastiCache for example for database and cache management services respectively. These managed services usually come turnkey and do not allow you to install packages on their instances.

To overcome this situation you can install an agent on another instance you have control over, for example a front end, and ask it to monitor a remote machine as well by giving it the ip and port of the managed service concerned.

For example, in the case of RDS you just have to deploy the agent "quanta-agent-mysql" (see the standard guide) and modify the agent configuration file "/etc/quanta/modules.d/mysqlstat.yml" to indicate the host and port of the managed service (IP and port).

Moreover if you use several instances of ElastiCache or equivalent (several types of cache as well as sessions) you can easily configure the Redis agent (or Varnish or Memcached) in order to indicate the different bases to target. The guide for this can be found here:

Add advanced metrics