Since we announced our support for Amazon Web Service's Aurora last year, we've had great experiences working with customers who use Aurora as their database system of choice. And not only is Amazon's RDS excellent, so is their team and support.

Recently, we encountered a MySQL bug that was, in turn, having effects on Amazon’s RDS. The MySQL issue involved a problematic query that caused Aurora instances to crash under load; upon discovering this issue, we had the opportunity to work with AWS to identify the error in MySQL and fix it, so that it would avoid an impact on AWS’s systems. It turned out that the query itself posed a potential problem for all monitoring services -- not just VividCortex; fortunately, however, once AWS addresses the bug, the problem will be fixed for all monitoring products that might come across it, …

In an industry as fast-growing and interconnected as database technology’s, it’s exciting to track how innovations in one platform can ignite beneficial, rippling effects on other, surrounding systems. At VividCortex we frequently find ourselves faced with opportunities to improve our monitoring solutions based on how database technologies (such as MySQL, Redis, PostgreSQL, etc) develop and integrate new upgrades.

When those platforms that we monitor -- already powerful, tried and true -- equip themselves with new features, we work to discover how VividCortex can leverage those features and make our own technology even better. In the case of MySQL 5.7.8’s recent introduction of Generated Virtual Columns, we found the opportunity to use a new feature to make our queries simpler and more elegant, with results …

In my last I was looking for a way to do performance monitoring and I stumbled upon Prometheus. Prometheus is much more than monitoring a single node service. Anyway let’s get the idea of gathering metrics using MySQL as example.

This how a simple configuration of Prometheus could look like:

global: 
  scrape_interval: 1m
  scrape_timeout: 10s
  evaluation_interval: 1m

scrape_configs:
  - job_name: mysql
    scheme: http
    target_groups:
    - targets: 
        - '10.17.148.31:9104'
      labels:
        zone: mysql

Every minute Prometheus accesses 172.17.148.31:9104/metrics (/metrics is a Prometheus convention) and labels the result with zone=mysql. Querying the data you can use the labels.

This is a simple configuration. The fun of Prometheus is to have a lot of targets/jobs.

Let’s have a look at our specific endpoint: …

Sylvia Botros, Sendgrid’s lead DBA, recently told us about one of the ways her teams have found unique value in VividCortex. “Engineering managers and individual developers have pinged me and said, ‘Hey, I saw this in VividCortex -- what do you think?’ Some of our developers are not fully familiar with the generals of MySQL,” she explained, “but VividCortex is giving them a view into how their app is dealing with databases. And at the same time it’s teaching them DB lingo, which is good.”  

This feedback from Sylvia opens the door to one of the questions we hear a lot about VividCortex: “How is your solution different from my existing APM (Application Performance Management) tool?”It’s a great question with many technical answers, but ultimately the only answers that matter are the ones focused on results. As an engineering-led company, we’re …

I've tried out Idera's MySQL Query Explorer, a free tool and I found it easy to use and simple to setup. The only improvement that can be suggested is to add, on the technical requirements page, that your MySQL instance (MySQL Server version 5.5 and newer) must be running with the performance_schema turned on. Otherwise the tool will just display an empty grid. After you've successfully set

VividCortex is designed to offer its users as much access and visibility into their database systems as possible. With that in mind, we're excited to let all of our MongoDB users know that VividCortex is capable of capturing, displaying, and navigating metrics and charts produced in MongoDB's powerful WiredTiger storage engine. 

Beginning with MongoDB version 3.0, users will have the option of selecting one of two storage engines: the default MMAPv1 engine, as used in prior MongoDB releases; or the new WiredTiger engine. As MongoDB's site explains,

For many applications, WiredTiger's more granular concurrency control and native compression will provide significant benefits in the areas of lower storage costs, greater …

We were just leafing through the 2015 edition of The DZone Guide to Database and Persistence Management, and we noticed some interesting stats in the guide's included survey, about which we'd like to share some observations. The survey is one of the ebook's central features, and it includes feedback from over 800 IT Professionals, with 63% of those respondents coming from companies with over 100 employees and 69% with over 10 years of experience -- they represent a significant and important cross-section of our industry.

These kinds of reports can be enlightening, as they offer the opportunity to take some of our principles and pin them to the hard facts and numbers of actual database activity, in the field. 

In a section titled "One Type of Database is Usually Not Enough," the report reveals that it's stadard …

I lost count of the number of times I had customers come to me for a regular MySQL performance check-up saying “no, we don’t have any performance problems right now”, just to find they do actually have them, they’re just not aware of it. It’s no big surprise this happens when you’re not using your system as actively as your users are.

So let me share with you one trick I’m using to quickly check if the system I’m on has any problems that need troubleshooting. Actually, it’s dead simple. And no, it’s not a slow query log, it’s Threads_running. Let me show you.

Wait, what’s wrong with the slow query log?

Nothing at all. MySQL’s slow query log is a great tool when you’re looking for slow queries. Or when you’re fishing for things to optimize – either to reduce the resource consumption, or to increase speed for queries you didn’t know are slow.

And it’s …

PGConf Silicon Valley was excellent this year: good organization, great speakers, and top-notch vibes in general. We were excited to see everybody visiting (and crowding!) our booth and the overall very positive community presence. Highlights included a presentation about Postgres' use at TripAdvisor, a look at Amazon RDS for Postgres, and consideration of system scalability and the future of relational database management systems.

Baron Schwartz, VividCortex's own founder and CEO, was at the Silicon Valley conference, and he's said that it was the best PGConf he's been to yet. On November 18th, Baron even led a breakout session, titled "Analyzing PostgreSQL Network Traffic with vc-pgsql-sniffer," in which he explained both the principles and practice that come together to result in VividCortex's powerful sniffer tools. Even the questions asked at Baron's talk were fantastic.

To watch a video of Baron's breakout session, find …

We've talked a lot about the high-resolution data we capture, but if you haven't experienced it yourself, it might be a little abstract. Here, look at the difference between 1-second and 1-minute data.

Are your monitoring systems glossing over important detail with low-frequency data?

All of our metrics are in 1-second granularity. That's 60x more data points per minute than most monitoring tools. It's 120x more data points per second than MongoDB Monitoring Service's premium paid tier. It's 500x more data points per minute than MySQL Enterprise Monitor at its default settings.

It's enough detail to see 1-second server stalls you will never find otherwise. This gives you the ability to proactively find and stop problems that will become much more serious over time.

And this data is not only realtime but …