Solve API problems fast with Runscope. Learn More →

Build a Health Check API for Services Underneath Your API

By Neil Mansilla on .

A running cat, in honor of National Cat Day. That's Oskar (click photo for original). Full attribution below.

running cat, in honor of National Cat Day. That's Oskar (click photo for original). Full attribution below.

Monitoring your API's health and performance is something Runscope can do very well. But what about monitoring the underlying services that your API relies on? Databases, like MySQL and Redis, or DNS services on BIND or Mara -- they don't come with RESTful APIs, and in fact, they communicate over lower-level protocols like TCP and UDP. 

When you're relying on services without monitoring, the only time you realize those services are down is when your API (or the apps that rely on your API) go down. Wouldn't it be great if those services had health check API endpoints?

Creating separate health check API endpoints for all services

One approach is to build simple health check API endpoints — a method similar to a ping that reports whether the service is up or down.  Consider building a health check endpoint for every service your backend relies on and using Runscope for testing, reporting and triggering notifications. If you use the same client library or SDK in the health check app that you use for your API backend, you'll have the additional benefit of dependency testing that client library.

That being said, include as few dependencies as possible, isolating the health check app to only what's necessary to connect to the service. I mean, you wouldn’t want a MySQL test to fail because Redis was down. The health check endpoint should do one thing, and one thing only — check that a single service is up and running. If so, return 200. If not, return 503.

MySQL service check example

Below is a pint-sized PHP sample app to test if a MySQL server is up. This app has no library dependencies. It's using PHP's integrated mysqli library. This app can be parked on any web server that can execute/interpret PHP files (e.g. Apache, Nginx, etc.). Ideally, it would be mapped to an endpoint route specifically for health check resources -- but in this example, I've just placed it in the home directory of a vanilla Apache instance. I have MySQL running on another box located on the local network (10.0.1.150) and bound to the default port (3306).

<?php
  $config = [
     "server"     => “10.0.0.150:3306",
     "username"   => "runscope",
     "password"   => "testpass"
  ];
  header('Content-type: application/json');

  $link = new mysqli($config['server'],$config['username'],$config['password']);

  if ($link->connect_errno) {
    http_response_code(503);
    echo('{ "status": "Unable to connect" }');
  }
  else {
    http_response_code(200);
    echo('{ "status": "Connection successful." }');
  }
?>

Ping! Test the endpoint with Runscope Radar Agent

Since my MySQL and Apache servers are behind the firewall, I'll be testing my new health check endpoint with Runscope Radar Agent. This agent will perform tests on the local network and report the results back to Runscope. The only requirement when using the remote Radar Agent is that the computer can make HTTPS requests. Read more about (and download) the Runscope Radar Agent here

After I ran the agent on my local machine (took only a minute to set up), it appeared as a testing location on my Runscope Radar test editor. The location titled Internal-SFO-Office in the screenshot below is my laptop that's running the Runscope Radara Agent.

Runscope Radar Test Editor view. After installing the Runscope Radar Agent on my local machine, it pops up in the list of testing locations.

Runscope Radar Test Editor view. After installing the Runscope Radar Agent on my local machine, it pops up in the list of testing locations.

Next, I clicked Run Now. The MySQL health check test ran from my local Radar Agent. Below were the results from Traffic Inspector.

Setting up notifications

Viola! The next step would be adding notifications, so that if there is a failure, the correct individual or team could receive email notifications. Additionally, Runscope supports webhooks, so that after tests run, succeed, or fail, Runscope can POST the test result data to any URL. Lastly, if you use PagerDuty, HipChat, Slack, Zapier, etc., Runscope smoothly integrates with all of those services. Read more about notifications here.

Should these be public or private?

You might ask yourself whether these endpoints should be made public or private. The short answer is private. By private, I mean that these should be treated as internal to your company, and not shared with partners or third party consumers of your API. Why? Because the information is too granular and could reveal details about your infrastructure that shouldn't be made public. However, if you were to wrap up all of these micro health checks together, and return a more abstract status response, that would be appropriate as a publicly accessible endpoint.

More micro sample health check apps on GitHub

In addition to the PHP+MySQL sample above, we've built a couple of other examples: Python+Redis, .Net/C#+MS-SQL and Perl+DNS. You're more than welcome to contribute your own. The GitHub repo is located here.

If you need some tips on how to get these health check apps working, or help with setting up Runscope Radar tests against them, our support team is standing by, happy to help.

p.s. I'll be following up with a blog post about a more comprehensive, open source, service health check project that's being worked on here at Runscope.

Cat photo attribution:  LInk to original photo here (Flickr user Tambako). Used under Creative Common license.

Categories: api, code samples

Add Runscope Logging to Your ASP.NET Web API in minutes

By Darrel Miller on .

If you are building an ASP.NET Web API and want a view into the HTTP traffic that is hitting your API then this is a really quick solution that might prove useful.

Add a MessageHandler

In your Web API project, simply add the Nuget package Runscope.HttpMessageHandler and the following line of code in your Web API configuration code:

config.MessageHandlers.Add(new RunscopeApiMessageHandler(<ApiKey>,<BucketKey>);

You can get an API key by creating an Application within Runscope. 

  1. Login to your Runscope account
  2. Click on your name on the top-right to access your profile
  3. Select Applications on the left-side menu
  4. Click the Create Application button

You'll find the bucket key from the Traffic Inspector view. It's located at the bottom of the left-side menu.

And you’re done.

Let me show you...

The following screencast demonstrates how to create an ASP.NET Web API, setup a Runscope account and add Runscope logging to your API in less than 5 minutes.

Image Credit : Monitor https://flic.kr/p/4druiD

Categories:

Q&A with Ryan Park: Runscope Engineer and AWS Community Hero

By Neil Mansilla on .

Ryan is a Principal Engineer at Runscope. Recently, Ryan was included in the AWS Community Hero Program. The program was created by Amazon Web Services to recognize AWS experts who go above and beyond to share their expertise and knowledge with the greater cloud community. Prior to Runscope, Ryan led technical operations at Pinterest, and before that, at PBworks. I sat down with Ryan and asked him to share a few things about himself and a few Runscope behind-the-scenes facts.

Q: What is your role at Runscope? What are the main types of problems that you focus on?

I'm a member of the software engineering team at Runscope, where I focus on technical operations. "Technical operations" encompasses the work that keeps Runscope up and running: setting up new infrastructure, identifying performance bottlenecks, and building tools to make this work easy and automatic.

Q: How does Runscope use Amazon Web Services?

Runscope runs most of its server infrastructure on Amazon EC2 (although some service regions are powered by other providers). Amazon EC2 is the most comprehensive cloud platform on the market right now, with features like private networking, a strong API, and 9 locations around the world.

We also use Amazon DynamoDB to store data for many of our microservices, and we use Amazon Route 53 to manage our DNS. Route 53's latency-based routing lets us route customer traffic to the nearest service region, which helps us provide a fast experience for all our customers around the world.

As a small (but growing) engineering team, it's been incredibly helpful to be able to rely on a service provider like Amazon to run our low-level infrastructure. As an example, earlier this month we added a service region in Japan. Thanks to Amazon's global presence, it only took us a couple hours of engineering to expand our service to Japan.

Q: Does Runscope use a lot of other cloud services? Which components are managed in-house, and which components are trusted to Runscope's partners?

Yes, we've relied heavily on cloud services for many parts of our infrastructure. For example, we've used Keen IO to power some of the performance and usage analytics in Runscope Metrics. We also use lower-level services like Mandrill to deliver email notifications to our customers.

We believe it's important to focus on our core competency -- API debugging and testing -- and to control our own infrastructure when it's directly relevant to those core competencies. We're happy to rely on our partners to keep everything else up and running.

Have a penchant for DevOps? We're hiring!

Runscope is looking for a DevOps Engineer to plan, build and automate a modern distributed and service-powered infrastructure. To find out more about what it's like to work at Runscope and see other open positions, visit this page.

 

Categories:

Insights from New Relic's FutureStack Conference

By Neil Mansilla on .

At New Relic’s FutureStack conference, Runscope was on the ground as a partner, sponsor and exhibitor. Over one thousand attendees came to Fort Mason in San Francisco to learn about New Relic’s application performance monitoring (APM) and other partner solutions. Runscope had product and engineering team members available to talk shop about API testing, monitoring and engage in friendly games of 4-player Mario Kart. What did we learn after two days of non-stop conversations with developers, hundreds of Runscope live demos and countless laps around Mario Kart Stadium?

Developers prefer simplicity: assertions with no coding required

A Runscope feature that developers loved was being able to define test assertions without programming. The most common assertion criteria (i.e. response code, JSON and XML object key values, response size, response time, etc.) and comparison operators can be configured through an intuitive user interface. Scripted (JavaScript) assertions are also available for those that require more advanced logic in their tests.

Developers love webhooks

Part of our live demo included the integration with New Relic’s analytics and dashboard tool, Insights. With just two input fields and a click, test data is instantly synced with Insights. By far, the most common followup questions asked were, “What data is being sent to Insights?” and “Can I send the data to our internal data warehouse?” The answers: everything and yes, respectively.

Runscope makes it a snap to integrate with other services like New Relic Insights, PagerDuty, Keen IO, Slack and HipChat; however, pumping Runscope Radar test data into any of your apps can be done using webhooks and the Runscope API. All of the important test result data, such as assertion status, response time (ms), response size (bytes) and more, is included in both webhooks and the API.

Kids just aren’t just coding, they’re keynoting

Sporting Google Glass, 12 year old developer Alannah Forster was happy to talk to anyone about her coding skills and projects as she strolled around FutureStack. She even gave us some tips on how to hack on the fancy WiFi conference badges. On day two, she was up on the keynote stage with New Relic CEO, Lew Cirne. Meanwhile, back at the Runscope lounge, 14 year old developer and hackathon veteran David Tesler cleverly customized his title on his digital lanyard.

Overall, we had a great time at FutureStack connecting with hundreds of developers and the next generation of coders. If you’re a New Relic user and want integrate Runscope with Insights, click here to learn how.

Categories:

Everything is going to be 200 OK

Sign Up — Free!