Git Product home page Git Product logo

runbook's Introduction

Runbook

What is Runbook

Runbook is an OpenSaaS (Apache 2.0) monitoring service that allows you to perform automated "reactions" when issues are detected. Giving you the ability to automatically resolve DevOps alerts with zero human interaction.

Simply put, Runbook is what you would get if Nagios and IFTTT had a baby.

Status

Runbook is primarily in maintenance mode, pull requests will be reviewed and merged but this project is not currently under active development. It is suggested that newer users check out Automatron as an alternative.

Documentation

Developer and User docs can be found in the docs directory and on ReadTheDocs.

3 Step Deployment

You can easily deploy Runbook within a Docker container with 3 simple steps. This deployment should work for small environments, for larger environments checkout our Installation Guide.

  • Start a RethinkDB Container
$ sudo docker run -d --name rethinkdb rethinkdb
  • Start a Redis Container
$ sudo docker run -d --name redis redis
  • Start a Runbook Container (linking to Redis and RethinkDB)
$ docker run -d --name runbook -p 8000:8000 --link rethinkdb:rethinkdb --link redis:redis runbook/runbook

Once launched simply navigate to http://<serverip>:8000.

Docker Pulls

Build Status

Develop:

Build Status Coverage Status

Master:

Build Status Coverage Status

Contributing

Join the chat at https://gitter.im/Runbook/runbook Stories in Ready

At Runbook we follow the GitHub Flow, while it is not required that you create feature branches it does help keep code organized. Below are the basic getting started steps for setting up a repo to contribute.

Setting up your Repo

The first step in getting ready to contribute is forking our repository on github. Once it is forked you can clone that fork onto your desktop; this documentation is assuming you are working from a clone of your fork.

Cloning

To pull the repository to your local machine simply run the following.

$ git clone <url of your repo>

Creating a feature branch

We have two branches develop and master, all new code must be submitted to the develop branch. This branch is considered our testing branch; once all of the features in the develop branch are ready for production they will be merged to the master branch.

To start developing a new feature simply create a unique branch for that feature.

$ git checkout develop
$ git checkout -b new-feature

You can make your changes, commit them and when complete push them to your GitHub repo.

$ git push origin new-feature

Creating a pull request

Once your code is ready and on GitHub you can create a Pull Request via the GitHub UI. Once your pull request is created it is typically best practice to go to the bounty on Assembly and submit your work with a link to the pull request. If the feature you created does not have a bounty created yet, simply create one explaining what you've done and why.

Once the bounty or work is submitted it is best to add a comment to the pull request with a link to the bounty. This keeps the code review and merging process quick and easy.

Syncing your fork

Runbook is a very fast paced application, we are making major code changes frequently and it is important that you keep your fork in sync to avoid conflicts. PR's with conflicts will not be merged until those conflicts are removed. To keep your repository in sync you can follow these steps.

Setting the upstream repository

To synchronize with the upstream repository you must first define it as an upstream source.

$ git remote add upstream https://github.com/Runbook/runbook.git
Fetching and Merging updates

Once the upstream repository is set you can update your repo by fetching and merging the updates.

$ git checkout develop
$ git fetch upstream
$ git merge upstream/develop
$ git checkout master
$ git merge upstream/master

To keep your GitHub fork up to date you can push the changes to your origin repository

$ git push origin

runbook's People

Contributors

adidoit avatar bill-boulger avatar bshyong avatar dereckson avatar dethos avatar digitalhurricane avatar dimoreira avatar dustinrc avatar jalessio avatar madflojo avatar mjhea0 avatar noushi avatar sanrag avatar stnly avatar themetric avatar vcherkassky avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

runbook's Issues

Copy button for Reactions

Creating a lot of reactions is somewhat tedious. This would be a lot less tedious if we provided a copy button which let's you copy an existing reaction into a new one.

Monitor: Load Average

Check load average and return False is above defined threshold.

**This monitor will need to use SSH to gather details

TLS Support for MySQL monitors and reactions

Currently the MySQL based monitors and reactions do not support TLS connections. The reason for this is due to the fact that the MySQL libraries only support passing certificates and keys as files. Since the certificates and keys are input from users and it is not really desirable to write these to the file system, TLS is not in use.

Create auto populating Monitor forms

Currently the HTML forms for monitors are defined on a per monitor basis. Since the backend of these forms are wtforms based they can and should be auto populated with basic Jinja and HTML.

Cloud Server Auto-Scaling

Right now Runbook interacts with AWS, DigitalOcean, RackSpace, and Linode. It would be great to have the ability to auto-scale each one of these cloud hosting environments (depending on API availability).

DigitalOcean Floating IP reaction

DO recently announced a new functionality called a Floating IP. Within their API you can "unassign" and "assign" a floating IP to a droplet.

This is a perfect reaction and very similar to #311 for Linode.

Monitor: DNS queries

Allow users to specify a DNS name and record type (A, CNAME, AAAA, MX) and an expected value, or set of values (round-robin, failover, etc.).

Create single droplet

The DigitalOcean: Create new droplet reaction automatically appends a timestamp to the name of the droplet to avoid errors when creating a new droplet.

This should probably be a feature that can be enabled and disabled. The reaction should also look at the list of existing images to see if a droplet by the same name already exists.

This allows users to setup the reaction to either create one or multiple new droplets.

One click duplicate for Runbooks and Reactions

Provide a duplicate button that copies all the values of a current Runbook / Reaction and opens the editor to adjust those values. Perfect for when you want to change a variable if a service is down and restore it when it's back up.

SSH Command Monitor

Now that #323 is closed sensitive information like SSH keys or usernames and passwords can be stored in the DB. With this limitation removed we can now work on monitors that are based on SSH calls.

The first can be a simple "execute command" monitor, which could be used to execute other health checks such as Nagios scripts or pretty much any other monitoring scripts out there.

Monitor: DB query

Databases are a good item to start monitoring. This monitor should be as simple as querying a remote database with a specified username and password.

The monitor however should also have the option to look at the queries results and do some basic matching/counting.

Copy button for Monitors

Creating a lot of runbooks is somewhat tedious. This would be a lot less tedious if we provided a copy button which let's you copy an existing monitor/runbook into a new one.

Related to #332

Create authentication "vault" for monitors and reactions

One commonly annoying thing is having to add API keys, Username/Passwords, SSH Keys and what not to each monitor/reaction manually. It would be best to create a "key vault" that allows users to put in those details once and use a select box for each monitor/reaction.

At some point it would be worthwhile to introduce multiuser accounts and I see the key vault being an admin function. This would let basic users setup monitors without knowing any sensitive details about the target system.

Variabilize Reaction Messages

Having the reaction message configured in the reaction itself doesn't allow you to specify the Runbook that failed. Reactions should either have some templating allowing you to use variables to specify the name of the runbook that failed, or the failure message should be configured in the Runbook settings.

Monitor: Filesystem usage

Verify a specified filesystem (or all filesystems if unspecified) have adequate space available.

Should work on Linux and BSD based systems.

Test Reaction

We used to have this as an open bounty on Assembly but it didn't move over with the repo. One requested feature is the ability to test a reaction with a click of a button.

This should be easy enough to create maybe just create a psuedo monitor and send it to the actioners via the bridge like a traditional webhook.

Modularize Statistics

Recently the payment system has been modularized to allow for a Self Hosted or Stripe option. In preparation for a big push of the open source Runbook deployment this will be very handy and allow for something other than StatHat.

Delete undo button / confirmation

Either provide an undo functionality after the delete occurs (preferred) or confirm that they wish to delete - it's close to the edit button so it's easy to misclick

Create auto populating reaction forms

Currently the HTML forms for reactions are defined on a per reaction basis. Since the backend of these forms are wtforms based they can and should be auto populated with basic Jinja and HTML.

Add encryption for monitor and reaction sensitive data

One of the key foundations for runbook so far has been that no passwords should be used as the data is not encrypted.

If we added encryption of monitor and reaction data we would then open the doors to a lot of functionality like monitoring a database service, HTTP Basic Auth or even performing SSH based monitors.

This one may take a bit but I think it is important to add.

Modularize logging

Right now all logging is done via syslog. While this is good as we move further to a general open source platform it's important to be able to build additional options. With that said it would be good to come up with a scheme that allows for anyone to pop in a module to add additional logging mechanisms like going to redis, rethinkdb, elastisearch or a generic file.

Create Import/Export functionality for Runbooks

Manually creating a bunch of monitors is kind of a pain. It would be nice to have an import/export function that allows users to create a new monitor/reaction combo.

Ideally this could be part of a first step towards an end user API.

Change the license

Find a more appropriate license to use for Runbook.

MIT and Apache licenses seem good, BSD is another option.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.