Vonage Uses InfluxData to Monitor and Manage Its Global SaaS Offering

Overview

Real-time visibility for a platform built to never stop

Vonage, formerly NewVoiceMedia, provides a global cloud contact center platform that helps businesses manage customer interactions across voice, email, social media, and other channels. For a platform built around real-time communication, reliability is critical. Vonage committed to 99.999% availability, while operating an infrastructure that spanned six clouds, roughly 1,000 servers, and customers in more than 100 countries.

At peak periods, the platform handled approximately 500,000 requests per minute, 5,000 concurrent calls, and as many as 1 million calls on a busy day. At the same time, the company’s customer base was growing rapidly, roughly doubling year over year.

Maintaining performance at that scale required more than knowing whether a server was up or down. Engineers needed to understand subtle changes in application, database, and infrastructure behavior quickly enough to act before customers noticed a problem.

Vonage turned to InfluxDB to collect high-resolution telemetry across its environment, analyze changes as they happened, and create a common destination for operational data from across its technology stack.

Challenge

See problems before customers do

Vonage’s existing monitoring tools could show engineers that something had gone wrong, but they did not always provide enough resolution to show what happened in the moments leading up to it. Some metrics were collected only once every one to five minutes. For relatively stable infrastructure, that might be sufficient. For a real-time communications platform, it could conceal the events engineers cared about most.

A CPU spike or change in request latency lasting 30 seconds, for example, could disappear entirely between two one-minute samples. That created a fundamental problem: by the time a monitoring system clearly showed that performance had degraded, customers might already have experienced it.

As Tench described the limitation:

Vonage wanted one-second and sub-second telemetry, but that meant handling roughly 20,000 to 30,000 points per second without making monitoring prohibitively expensive.

The team also wanted more control over its data: how long metrics were retained, how historical data was rolled up, how telemetry could be queried, and how information from applications, databases, infrastructure, and third-party tools could be combined.

The need extended into development. As Vonage shipped software more frequently, engineers wanted telemetry to help them compare new features with existing implementations, understand performance, and determine whether new code could scale before release.

Enter InfluxDB

Catching database replication lag before it impacts customers

Vonage adopted InfluxDB as the time series foundation for its monitoring environment.

One of the first use cases focused on database replication. Vonage’s database infrastructure included roughly 40 to 50 database servers spread across regions. When load increased, a replica could begin falling behind, leaving different parts of the application operating on inconsistent state.

Traditional infrastructure metrics did not always provide an early warning. CPU and network utilization could still look normal even as replication lag increased. Vonage began continuously measuring replication delay and storing the data in InfluxDB. Engineers could visualize it in Grafana and see when a database began struggling before more obvious symptoms appeared.

The above shows the final architecture that they have adopted (MySQL is just one example). They use Telegraf as a local agent and can collect all the stats from MySQL with a simple configuration change as well as any local StatsD stats. And with their move to Docker containerization, it is easy to drop the Telegraf agent into every service as they spin up and down the container to monitor for local system health and plug into whatever service happens to be in the container (MySQL, RabbitMQ, etc).

They also still use Telegraf as a central server to listen to StatsD from anything — this makes it easy to put StatsD code into any service, legacy or experimental systems, and have the metrics be sent to InfluxDB.

From one use case to a shared telemetry layer

The database project changed how Vonage approached operational data.

Telegraf collected system metrics such as CPU, disk, and network activity, along with data from services including MySQL. Applications could send custom metrics through StatsD, while engineers could also bring data from scripts and other monitoring systems into InfluxDB.

When engineers identified a new metric worth tracking, they could create it and begin collecting data in roughly 10 minutes.

As adoption grew, the production environment reached approximately:

• 2,000 measurements
• 200 million series
• 20,000+ points written per second
• 20 queries per second

InfluxDB also gave Vonage more control over retention. Some external monitoring systems provided only about one week of historical data. In InfluxDB, Vonage could retain high-resolution data where needed, roll up older telemetry, and keep some historical data for as long as two years.

Result

Faster releases, with greater confidence

InfluxDB grew from a solution for one database-monitoring problem into a shared foundation for how Vonage built, released, and operated its global platform.

Detect problems before customers do: Moving from one-to-five-minute monitoring intervals to high-resolution telemetry gave engineers visibility into events that slower monitoring could miss, including 30-second performance spikes and increases in database replication lag.

Validate new features before release: Engineers could instrument new code, compare its performance with existing implementations, and determine whether it could scale to meet Vonage’s service levels before releasing it more broadly.

Keep more data for deeper analysis: Instead of being limited to roughly one week of history in some external systems, Vonage could retain rolled-up metrics for as long as two years.

Ship more frequently with greater confidence: The main product moved from releases roughly once every couple of weeks toward daily releases. Newer microservices moved even faster, with one team reaching as many as eight full global production releases in a single day.

Build a common foundation for operational data: With approximately 2,000 measurements, 200 million series, and more than 20,000 points per second flowing into the system, InfluxDB became the place Vonage increasingly brought operational data when engineers wanted to understand it over time.