Skip to content
master
Switch branches/tags
Code

Latest commit

Region is obtained in the following order:
1. Get it from the surfacer config if specified.
2. Get it from EC2 metadata variables if available.
3. Finally, if no region is given, AWS SDK falls back to the AWS_REGION and AWS_DEFAULT_REGION environment variables.

PiperOrigin-RevId: 404735455
815ba86

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
cmd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
rds
 
 
 
 
 
 
 
 
 
 
 
 
 
 
web
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Go Build and Test Appveyor Build status Docker Pulls

Cloudprober is a monitoring software that makes it super-easy to monitor availability and performance of various components of your system. Cloudprober employs the "active" monitoring model. It runs probes against (or on) your components to verify that they are working as expected. For example, it can run a probe to verify that your frontends can reach your backends. Similarly it can run a probe to verify that your in-Cloud VMs can actually reach your on-premise systems. This kind of monitoring makes it possible to monitor your systems' interfaces regardless of the implementation and helps you quickly pin down what's broken in your system.

Cloudprober Use Case

Features

  • Automated target discovery for Cloud targets. GCE and Kubernetes are supported out-of-the-box, other Cloud providers can be added easily.
  • Integration with open source monitoring stack of Prometheus and Grafana. Cloudprober exports probe results as counter based metrics that work well with Prometheus and Grafana.
  • Out of the box, config based integration with popular monitoring systems: Prometheus, DataDog, PostgreSQL, StackDriver, CloudWatch.
  • Fast and efficient built-in implementations for the most common types of checks: PING (ICMP), HTTP, UDP, DNS. Especially PING and UDP probes are implemented in such a way that thousands of hosts can be probed with minimal resources.
  • Arbitrary, complex probes can be run through the external probe type. For example, you could write a simple script to insert and delete a row in your database, and execute this script through the 'EXTERNAL' probe type.
  • Standard metrics - total, success, latency. Latency can be configured to be a distribution (histogram) metric, allowing calculations of percentiles.
  • Strong focus on ease of deployment. Cloudprober is written entirely in Go, and compiles into a static binary. It can be easily deployed, either as a standalone binary or through docker containers. Thanks to the automated, continuous, target discovery, there is usually no need to re-deploy or re-configure cloudprober in response to most of the changes.
  • Low footprint. Cloudprober docker image is small, containing just the statically compiled binary and it takes very little CPU and RAM to run even a large number of probes.
  • Extensible architecture. Cloudprober can be easily extended along most of the dimensions. Adding support for other Cloud targets, monitoring systems and even a new probe type, is straight-forward and fairly easy.

Getting Started

Visit Getting Started page to get started with Cloudprober.

Feedback

We'd love to hear your feedback. If you're using Cloudprober, would you please mind sharing how you use it by adding a comment here. It will be a great help in planning Cloudprober's future progression.

Join Cloudprober Slack or Github discussions for questions and discussion about Cloudprober.