EmergencyEMERGENCY? Get 24/7 Help Now!

Three Methods of Installing Percona Monitoring and Management

 | June 15, 2017 |  Posted In: MongoDB, MySQL, Percona Monitoring and Management

PREVIOUS POST
NEXT POST

Installing Percona Monitoring and ManagementIn this blog post, we’ll look at three different methods for installing Percona Monitoring and Management (PMM).

Percona offers multiple methods of installing Percona Monitoring and Management, depending on your environment and scale. I’ll also share comments on which installation methods we’ve decided to forego for now. Let’s begin by reviewing the three supported methods:

  1. Virtual Appliance
  2. Amazon Machine Image
  3. Docker

Virtual Appliance

We ship an OVF/OVA method to make installation as simple as possible, with the least amount of effort required and at the lowest cost to you. You can leverage the investment in your virtualization deployment platform. OVF is an open standard for packaging and distributing virtual appliances, designed to be run in virtual machines.

Using OVA with VirtualBox as a first step is common in order to quickly play with a working PMM system, and get right to adding clients and observing activity within your own environment against your MySQL and MongoDB instances. But you can also use the OVA file for enterprise deployments. It is a flexible file format that can be imported into other popular hypervisor systems such as VMware, Red Hat Virtualization, XenServer, Microsoft System Centre Virtual Machine Manager and others.

We’d love to hear your feedback on this installation method!

AWS AMI

We also have an AWS AMI in order to provide easy scaling of PMM Server in AWS, so that you can deploy onto any instance size required for your monitoring instance. Depending on the AWS region you’re in, you’ll need to choose from the appropriate AMI Instance ID. Soon we’ll be moving to the AWS Marketplace for even easier deployment. When this is implemented, you will no longer need to clone an existing AMI ID.

Docker

Docker is our most common production deployment method. It is easy (three commands) and scalable (tuning passed on the command line to Docker run). While we recognize that Docker is still a relatively new deployment system for many users, it is dramatically gaining adoption. It is also where Percona is investing the bulk of our development efforts. We deploy PMM Server as two Docker containers: one for storing the data that persists across restarts/upgrades, and the other for running the actual PMM Server binaries (Grafana, Prometheus, consul, Orchestrator, QAN, etc.).

Where are the RPM/DEB/tar.gz packages?!

A common question I hear is why doesn’t Percona support binary-based installation?

We hear you: RPM/DEB/tar.gz methods are commonly used today for many of your own applications. Percona is striving for simplicity in our deployment of PMM Server, and we spend considerable development and QA effort validating the specific versions of Grafana/Prometheus/QAN/consul/Orchestrator all work seamlessly together.

Percona wants to ensure OS compatibility and long-term support of PMM, and to do binary distribution “right” means it can quickly get expensive to build and QA across all the popular Linux distributions available today. We’re in no way against binary distributions. For example, see our list of the nine supported platforms for which we provide bug fix support.

Percona decided to focus our development efforts on stability and features, and less on the number of supported platforms. Hence the hyper-focus on Docker. We don’t have any current plans to move to a binary deployment method for PMM, but we are always open to hearing your feedback. If there is considerable interest, then please let me know via the comments below. We’ll take these thoughts into consideration for PMM planning in the second half of 2017.

Which other methods of installing Percona Monitoring and Management would you like to see?

PREVIOUS POST
NEXT POST
Michael Coburn

Michael joined Percona as a Consultant in 2012 after having worked with high volume stock photography websites and email service provider platforms. With a foundation in Systems Administration, Michael enjoys working with SAN technologies and high availability solutions. A Canadian, Michael currently lives in Costa Rica with his wife, two children, and two dogs.

14 Comments

    • Thanks for the feedback – have you used our AMI? Yes I appreciate the irony that EC2 is virtualisation as well, but at least that is one, and only one level of virt. 🙂

          • DEB/RPM/etc. Even having to compile the software myself is better than using a virtualizer just for 1 purpose, but given the Open Source nature someone will compile it the standard way if the devs won’t.

            There are continuous integration systems and you’ve virtualized systems such as Debian for this purpose and you can control different Linux distro types with same remote control softwares, so I don’t see how spinning a DEB/RPM/… would be such a hassle not worth it.

  • We would greatly appreciate DEB packages but absolutely understand the extra effort it would require you to build and support that. Thanks for the explanation about development focus.
    So far, the Docker image (and the proposed other two solutions) held us back from using PMM alltogether – and we are probably not the only ones out there who make this decision. Bad PR for PMM, which surely is a great product!

    We could perfectly live with one of the following two options:

    – LXC package (a simple .tar.gz, could be probably easily ported from Docker image. or can I easily do this by myself via docker export?)
    – Omnibus package (as GitLab uses now for several years, works like a charm, no upgrade issues ever! Chef-based)

    That would be great! Thanks Michael for listening to the crowd.

  • we use rackspace not AWS, so this is limiting for me to easily install., and i have been wanting to install directly to a linux VM, without having to install docker

    • Thanks Jason for your note. I’ve added Rackspace support to our list for future installation candidates.

  • Agreed with the above responses. I’d prefer a deb package (especially like the Omnibus that GitLab uses as somebody mentioned above), especially because I can automate a server deployment with Ansible.

    We also use Rackspace, so its also difficult to install.

Leave a Reply to Jouni Järvinen Cancel reply