Last month, our new Director of Product wrote a blog about all the cool things she learned about how we track Percona Monitoring and Management (PMM) adoption and even went into what conclusions we can draw from that. As you can imagine, I was excited she geeked out on what little data we gather just like I do; you can make much better decisions even with just a little information! So why are we talking about it again? Well, we’ve enhanced the telemetry endpoint to enable us to deliver even more value in the future and wanted to make sure we do so as transparently as possible.
So What Exactly Are We Doing?
We’ve stood up a new telemetry micro-service (I’ll have to get one of our architects to blog about that, but guess what we’ll be using to monitor and alert with!) that will let us eventually retire the legacy endpoint after we run them in parallel for a bit. This one will be FAR more flexible than the current one and will allow us to maintain separation of purely anonymous data and that of our subscribers (which isn’t actually built yet but baby steps).
Why Are We Doing It?
Well, to deliver better service, of course. The basic anonymous data helps us determine where we need to focus our development dollars and understand both the makeup and uptake of the various versions of PMM. This helps determine if we need to release patches to legacy versions that may not technically be supported all the way to how the frequency of release impacts adoption. We also are looking to deliver MORE services and many of them will require we know a little more about the user. That subscriber service I mentioned earlier is just that. When it’s done you’ll be able to register for a free Percona account which will allow us to gather slightly more detailed information (don’t freak out, I have a whole section on transparency coming up) and turn that into more actionable information for you (did you know that MySQL 8.0.12 is vulnerable to 105 CVE’s most with a CVSS of 4.0 or greater…how many servers do you have that are impacted by that?)
Ummm…Can You Talk About That Transparency Part?
As far as the currently collected anonymous data we gather only the following: PMM Version, Installation Method (Docker*, AMI, OVF), and Uptime. We do not capture anything that would make you identifiable (we get Country Code from the submitting IP address before it’s discarded) however we do create an “instance ID” which is just a random string we generate using UUID v4 to decide if we’re hearing from a new instance or an existing one for figuring out instance upgrades and the like. We’ve also put a landing page up at the new endpoint check.percona.com to clearly identify what this service is, what it’s collecting, and how you can turn it off. Finally, we’re delaying the first reporting of a new instance by 24 hours to allow sufficient time to disable the service for those that do not wish to share any information. The documentation has also been drastically improved: we had a link to “more information” that contained no relevant information (fixed!) and are highlighting how to disable telemetry more prominently in our online docs. And of course, we’re also an open source company, you can look at the logic for what we’re gathering and how by looking here and here.
So what’s next?
That’s the exciting part, our goal with Percona Monitoring and Management is to be able to drive you to take action! I mentioned letting you know about CVEs but that’s the tip of the iceberg. Percona has always made its money through selling our database expertise via services, support and consulting while giving away our software. Registered users and current customers will now be able to get some of that expertise delivered and applied directly to their environments. Our roadmap is overflowing with ideas to help you not only maintain awareness of what’s going on in your database infrastructure but to be more proactive about spotting problems before they become outages!
While I hope you are equally as excited about what we’re working on, but if you just don’t feel comfortable sharing any information, we wouldn’t be true to our word if we didn’t include instructions here on how to opt-out: You can easily switch this off via the on/off switch for Call home (<=PMM 2.3) or Telemetry (>=PMM 2.4) on the PMM Settings panel off the main dashboard.
For those of us who exist almost entirely on the command line, you can also disable telemetry on container initialization by adding ‘-e DISABLE_TELEMETRY=1’ to your ‘docker run’ command.
If you have thoughts on additional insights you’d like to get from Percona or on our approach, please comment below.
*Prior to PMM 2.4 we detected the OS of the PMM server and made the decision on our server if it was Docker vs AMI vs OVF now we only capture Docker, AMI or OVF.
