<commit_before><!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-generate-toc again -->
**Table of Contents**

- [Overview](#overview)
- [Installation and Usage](#installation-and-usage)
    - [Installation/Building](#installationbuilding)
    - [Usage](#usage)
    - [Supported Frameworks](#supported-frameworks)
- [Checks](#checks)
- [Dependencies](#dependencies)
- [Comparison to Other Software](#comparison-to-other-software)
    - [Serverspec](#serverspec)
    - [Nagios](#nagios)
- [Contributing and Getting Help](#contributing-and-getting-help)
    - [Contributing](#contributing)
    - [Getting Help](#getting-help)
- [License](#license)

<!-- markdown-toc end -->

Overview
========

This readme documents the current (development) version of distributive.

Distributive is a tool for running distributed health checks in datacenters.
It was designed with Consul in mind, but is platform agnostic. It is simple
to configure (with JSON checklists) and easy to deploy and run. It has no
dependencies, and can be shipped as a speedy 1.3MB (yes, megabytes!) binary.

Usually, some external server will ask the host to execute this program, reading
a checklist from a JSON file, and will record this program's exit code and
standard out. Distributive's output includes information about which checks
in a checklist failed, and how so.

The exit code meanings are defined as [Consul][consul], [Kubernetes][kubernetes],
[Sensu][sensu], and [Nagios][nagios] recognize them.

 * Exit code 0 - Checklist is passing
 * Exit code 1 - Checklist is warning
 * Any other code - Checklist is failing

As of right now, only exit codes 0 and 1 are used, even if a checklist fails.

Installation and Usage
======================

Installation/Building
---------------------

To install the development version (potentially unstable):
 1. Clone this repo: `git clone https://github.com/CiscoCloud/distributive`
 2. Get dependencies with `go get .` (or used versioned dependencies with
 [godep] [godep]).
 3. (Optional) Test with `go test -short ./...`
 4. Build a binary with `go build .`
 5. Follow the "Usage" instructions below

The Dockerfile demonstrates how to build it from scratch (without golang
installed, etc.).

We also provide premade RPM packages on [Bintray][bintray] for versioned
releases. You can view the RPM source and build RPM snapshots at
[distributive-rpm][distributive-rpm].

Usage
-----

The default behavior is to run all checks in /etc/distributive.d/ (the default
directory give to the `-d` option), in addition to any specified via the `-f`
`-u`, or `-s` options.

```
$ distributive --help
[...]
USAGE:
   Distributive [global options] command [command options] [arguments...]

VERSION:
   0.1.3

GLOBAL OPTIONS:
   --verbosity "warn"           info | debug | fatal | error | panic | warn
   --file, -f                   Read a checklist from a file
   --url, -u                    Read a checklist from a URL
   --directory, -d "/etc/distributive.d/"   Read all of the checklists in this directory
   --stdin, -s                  Read data piped from stdin as a checklist
   --help, -h                   show help
   --version, -v                print the version
```

Examples:

```
$ /path/to/distributive --verbosity="warn" -f ./samples/filesystem.json
$ distributive -d="" --f="/etc/distributive/samples/network.json" --verbosity=debug
$ ./distributive -d="" -u "http://pastebin.com/raw.php?i=5c1BAxcX"
$ /distributive --verbosity="info"
$ /path/to/distributive -d "/etc/distributive.d/"
$ cat samples/filesystem.json | ./distributive -d "" -s=true --verbosity=fatal
```

Supported Frameworks
--------------------

Distributive attempts to be as framework-agnostic as possible. It is known to
work well with Consul, Kubernetes, Sensu and Nagios, which have similar design
in how they detect passing and failing checks. There is documentation on how to
use Distributive with Consul on our [Github wiki][wiki].


Checks
=======

For the impatient, examples of every single implemented check are available in
the `samples/` directory, sorted by category. There is extensive documentation
for each check available on our [Github wiki][wiki].

If you'd like to see how Distributive is used in production environments, take
a look at the [RPM source][distributive-rpm], which includes checks used in
[Microservices-Infrastructure][mi].


Dependencies
============

Distributive itself has no dependencies; it is compiled as a statically linked
standalone Go binary. Some checks, however, rely on output from specific
packages. These dependencies are outlined for each check on our
[Github wiki][wiki].

Comparison to Other Software
============================

Distributive was created with the idea of pushing responsibiliy to the nodes,
It was also designed around the idea of constantly changing infrastructure, with
servers being added and destroyed constantly, changing IP addresses, and even
changing roles. Integration with Consul provides even
[greater flexibility](https://www.consul.io/intro/vs/nagios-sensu.html).

Serverspec
----------

Serverspec runs on a single control server, and requires each check to be in a
directory matching the hostname of the machine to run it on. Distributive was
designed for dynamic systems with changing IPs, which can report into Consul,
Sensu, or another framework as soon as they are ready, and require little or no
centralized configuration. Additionally, Distributive attempts to rely as little
as possible on external tools/commands, using mostly just the Go standard library.

Nagios
------

Nagios is an end-to-end monitoring, security, and notification framework. It
provides many services not included in Distributive, and solves a very different
problem.  Distributive is simple, lightweight, and easy to configure, and<commit_msg>Update README to match new default behavior<commit_after><!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-generate-toc again -->
**Table of Contents**

- [Overview](#overview)
- [Installation and Usage](#installation-and-usage)
    - [Installation/Building](#installationbuilding)
    - [Usage](#usage)
    - [Supported Frameworks](#supported-frameworks)
- [Checks](#checks)
- [Dependencies](#dependencies)
- [Comparison to Other Software](#comparison-to-other-software)
    - [Serverspec](#serverspec)
    - [Nagios](#nagios)
- [Contributing and Getting Help](#contributing-and-getting-help)
    - [Contributing](#contributing)
    - [Getting Help](#getting-help)
- [License](#license)

<!-- markdown-toc end -->

Overview
========

This readme documents the current (development) version of distributive.

Distributive is a tool for running distributed health checks in datacenters.
It was designed with Consul in mind, but is platform agnostic. It is simple
to configure (with JSON checklists) and easy to deploy and run. It has no
dependencies, and can be shipped as a speedy 1.3MB (yes, megabytes!) binary.

Usually, some external server will ask the host to execute this program, reading
a checklist from a JSON file, and will record this program's exit code and
standard out. Distributive's output includes information about which checks
in a checklist failed, and how so.

The exit code meanings are defined as [Consul][consul], [Kubernetes][kubernetes],
[Sensu][sensu], and [Nagios][nagios] recognize them.

 * Exit code 0 - Checklist is passing
 * Exit code 1 - Checklist is warning
 * Any other code - Checklist is failing

As of right now, only exit codes 0 and 1 are used, even if a checklist fails.

Installation and Usage
======================

Installation/Building
---------------------

To install the development version (potentially unstable):
 1. Clone this repo: `git clone https://github.com/CiscoCloud/distributive`
 2. Get dependencies with `go get .` (or used versioned dependencies with
 [godep] [godep]).
 3. (Optional) Test with `go test -short ./...`
 4. Build a binary with `go build .`
 5. Follow the "Usage" instructions below

The Dockerfile demonstrates how to build it from scratch (without golang
installed, etc.).

We also provide premade RPM packages on [Bintray][bintray] for versioned
releases. You can view the RPM source and build RPM snapshots at
[distributive-rpm][distributive-rpm].

Usage
-----

The default behavior is to run any checks specified via `-f`, `-u`, `-s`,
or `-d` options, or all checks in /etc/distributive.d/ if no location is
specified.

```
$ distributive --help
[...]
USAGE:
   Distributive [global options] command [command options] [arguments...]

VERSION:
   0.1.3

GLOBAL OPTIONS:
   --verbosity "warn"           info | debug | fatal | error | panic | warn
   --file, -f                   Read a checklist from a file
   --url, -u                    Read a checklist from a URL
   --directory, -d "/etc/distributive.d/"   Read all of the checklists in this directory
   --stdin, -s                  Read data piped from stdin as a checklist
   --help, -h                   show help
   --version, -v                print the version
```

Examples:

```
$ /path/to/distributive --verbosity="warn" -f ./samples/filesystem.json
$ distributive --f="/etc/distributive/samples/network.json" --verbosity=debug
$ ./distributive -u "http://pastebin.com/raw.php?i=5c1BAxcX"
$ /distributive --verbosity="info"
$ /path/to/distributive -d "/etc/distributive.d/" # same as default behavior
$ cat samples/filesystem.json | ./distributive -d "" -s=true --verbosity=fatal
```

Supported Frameworks
--------------------

Distributive attempts to be as framework-agnostic as possible. It is known to
work well with Consul, Kubernetes, Sensu and Nagios, which have similar design
in how they detect passing and failing checks. There is documentation on how to
use Distributive with Consul on our [Github wiki][wiki].


Checks
=======

For the impatient, examples of every single implemented check are available in
the `samples/` directory, sorted by category. There is extensive documentation
for each check available on our [Github wiki][wiki].

If you'd like to see how Distributive is used in production environments, take
a look at the [RPM source][distributive-rpm], which includes checks used in
[Microservices-Infrastructure][mi].


Dependencies
============

Distributive itself has no dependencies; it is compiled as a statically linked
standalone Go binary. Some checks, however, rely on output from specific
packages. These dependencies are outlined for each check on our
[Github wiki][wiki].

Comparison to Other Software
============================

Distributive was created with the idea of pushing responsibility to the nodes,
It was also designed around the idea of constantly changing infrastructure, with
servers being added and destroyed constantly, changing IP addresses, and even
changing roles. Integration with Consul provides even
[greater flexibility](https://www.consul.io/intro/vs/nagios-sensu.html).

Serverspec
----------

Serverspec runs on a single control server, and requires each check to be in a
directory matching the hostname of the machine to run it on. Distributive was
designed for dynamic systems with changing IPs, which can report into Consul,
Sensu, or another framework as soon as they are ready, and require little or no
centralized configuration. Additionally, Distributive attempts to rely as little
as possible on external tools/commands, using mostly just the Go standard library.

Nagios
------

Nagios is an end-to-end monitoring, security, and notification framework. It
provides many services not included in Distributive, and solves a very different
problem.  Distributive is simple, lightweight, and easy to configure, and
{'fraction_non_alphanumeric': 0.10914227015921932, 'fraction_numerical': 0.002739256976545112, 'mean_word_length': 3.776369582992641, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 4, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4564387', 'n_tokens_mistral': 3320, 'n_tokens_neox': 3104, 'n_words': 1405}