Merge pull request mozilla-services#1807 from nikai3d/dev

Fix typos in docs

Author: rafrombrc

docs/source/config/common_sandbox_parameter.rst

@@ -3,7 +3,7 @@
 Common Sandbox Parameters
 =========================
 These are the configuration options that are universally available to all
-Sandbox plugins. The are consumed by Heka when it initializes the plugin.
+Sandbox plugins. They are consumed by Heka when it initializes the plugin.
 
 - script_type (string):
     The language the sandbox is written in. Currently the only valid option is

docs/source/config/decoders/geoip.rst

@@ -47,7 +47,7 @@ Config:
     The name of the new field created by the decoder. The decoder will output
     a JSON object with the following elements:
 
-        - latitute: string,
+        - latitude: string,
         - longitude: string,
         - location: [ float64, float64 ],
                 - GeoJSON format intended for use as a `geo_point <http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-geo-point-type.html/>`_ for ES output.

docs/source/config/decoders/multi.rst

@@ -31,7 +31,7 @@ Config:
     failed if *none* of the sub-decoders succeed.
 
 Here is a slightly contrived example where we have protocol buffer encoded
-messages coming in over a TCP connection, with each message containin a single
+messages coming in over a TCP connection, with each message containing a single
 nginx log line. Our MultiDecoder will run each message through two decoders,
 the first to deserialize the protocol buffer and the second to parse the log
 text:

docs/source/config/decoders/protobuf.rst

@@ -11,7 +11,7 @@ with other Heka instances, so one will always be included in your Heka
 configuration under the name "ProtobufDecoder", whether specified or not. The
 ProtobufDecoder has no configuration options.
 
-The hekad protocol buffers message schema in defined in the `message.proto`
+The hekad protocol buffers message schema is defined in the `message.proto`
 file in the `message` package.
 
 Example:

docs/source/config/filters/stat.rst

@@ -5,7 +5,7 @@ Stat Filter
 
 Plugin Name: **StatFilter**
 
-Filter plugin that accepts messages of a specfied form and uses extracted
+Filter plugin that accepts messages of a specified form and uses extracted
 message data to feed statsd-style numerical metrics in the form of `Stat`
 objects to a `StatAccumulator`.
 

docs/source/config/index.rst

@@ -102,7 +102,7 @@ Config:
 
 - max_pack_idle (string):
     A time duration string (e.x. "2s", "2m", "2h") indicating how long a
-    message pack can be 'idle' before its considered leaked by heka. If too
+    message pack can be 'idle' before it is considered leaked by heka. If too
     many packs leak from a bug in a filter or output then heka will eventually
     halt. This setting indicates when that is considered to have occurred.
 

docs/source/config/inputs/httplisten.rst

@@ -39,7 +39,7 @@ Config:
 
 - headers (subsection, optional):
     It is possible to inject arbitrary HTTP headers into each outgoing response
-    by adding a TOML subsection entitled "headers" to you HttpOutput config
+    by adding a TOML subsection entitled "headers" to your HttpOutput config
     section. All entries in the subsection must be a list of string values.
 
 .. versionadded:: 0.9

docs/source/config/inputs/process.rst

@@ -17,7 +17,7 @@ Config:
 
 - command (map[uint]cmd_config):
     The command is a structure that contains the full path to the binary,
-    command line arguments, optional enviroment variables and an optional
+    command line arguments, optional environment variables and an optional
     working directory (see below). ProcessInput expects the commands to be
     indexed by integers starting with 0, where 0 is the first process in the
     chain.

docs/source/config/outputs/dashboard.rst

@@ -36,7 +36,7 @@ Config:
 
 - headers (subsection, optional):
     It is possible to inject arbitrary HTTP headers into each outgoing response
-    by adding a TOML subsection entitled "headers" to you HttpOutput config
+    by adding a TOML subsection entitled "headers" to your HttpOutput config
     section. All entries in the subsection must be a list of string values.
 
 

docs/source/config/outputs/udp.rst

@@ -29,7 +29,7 @@ Config:
 	from the Heka message.
 - max_message_size (int):
 	Maximum size of message that is allowed to be sent via UdpOutput. Messages
-	which exceeds this limit will be dropped. Defaults to 65507 (the limit
+	which exceed this limit will be dropped. Defaults to 65507 (the limit
 	for UDP packets in IPv4).
 
 Example:

docs/source/developing/plugin.rst

@@ -833,7 +833,7 @@ output and the error.
 Unlike the other plugin types, encoders don't have a PluginRunner, nor do they
 run in their own goroutines. Outputs invoke encoders directly, by calling the
 Encode method exposed on the OutputRunner. This has the same signature as the
-Encoder interface's Encode method, to which it will will delegate. If
+Encoder interface's Encode method, to which it will delegate. If
 ``use_framing`` is set to true in the output's configuration, however, the
 OutputRunner will prepend Heka's :ref:`stream_framing` to the generated binary
 data.
@@ -874,7 +874,7 @@ of these is the ``Output`` interface::
   }
 
 The only difference between this and the :ref:`Filter <filters>` interface is
-that the first argument to ``Prepare`` is and ``OutputRunner`` and not a
+that the first argument to ``Prepare`` is an ``OutputRunner`` and not a
 ``FilterRunner``. The two interfaces are used in the same way, with Prepare
 being called before message processing starts and CleanUp being called after
 message processing has completed.

docs/source/getting_started.rst

@@ -451,7 +451,7 @@ Heka Dashboard
 ==============
 
 At this point it's useful to notice that, while the SandboxFilter gathers the
-data that we're interested in and packages it up an a format that's useful for
+data that we're interested in and packages it up in a format that's useful for
 graphing, it doesn't actually *do* any graphing. Instead, it periodically
 creates a message of type `heka.sandbox-output`, containing the current
 circular buffer data, and injects that message back into Heka's message
@@ -659,7 +659,7 @@ by `Logstash <http://logstash.net/>`_ (specifically intended for HTTP request da
 natively supported by Kibana), and the :ref:`config_espayload`, which assumes
 that the message payload will already contain a fully formed JSON document
 ready for sending to ElasticSearch, and just prepends the necessary Bulk API
-segement.
+segment.
 
 In our `ESJsonEncoder` section, we're mostly adhering to the default settings.
 By default, this decoder inserts documents into an ElasticSearch index based
@@ -819,7 +819,7 @@ Gaussian distribution, such as cases where the set of data points is sparse.
 
 The next argument tells us what column we'll be looking at. In this case we're
 using column 5, which is where we store the 500 range status responses, or
-server errors. After that is the number of intervals to use in a analysis
+server errors. After that is the number of intervals to use in an analysis
 window (15), followed by the number of analysis windows to compare (10). In
 this case, that means we'll be examining the last 15 seconds, and comparing
 what we find there with the 10 prior 15 second windows, or the 150 previous

docs/source/installing.rst

@@ -23,7 +23,7 @@ From Source
 this task is automated by the build process. The build script will override the
 Go environment for the shell window it is executed in. This creates an isolated
 environment that is intended specifically for building and developing Heka.
-The build script should be be sourced every time a new shell is opened for Heka
+The build script should be sourced every time a new shell is opened for Heka
 development to ensure the correct dependencies are found and being used. To
 create a working `hekad` binary for your platform you'll need to install some
 prerequisites. Many of these are standard on modern Unix distributions and all
@@ -161,7 +161,7 @@ sub-packages to be initialized.
         # is checked in, the value can simply be changed to the correct tag to make it 'live'.
         # i.e. {heka root}/externals/heka-sns-input -> {heka root}/build/heka/src/github.com/bellycard/heka-sns-input
 
-The preceeding entry clones the `heka-mozsvc-plugins` git repository into the Go
+The preceding entry clones the `heka-mozsvc-plugins` git repository into the Go
 work environment, checks out SHA 6fe574dbd32a21f5d5583608a9d2339925edd2a7, and imports the package into 
 `hekad` when `make` is run. By adding an `init() function <http://golang.org/doc/effective_go.html#init>`_ 
 in your package you can make calls into `pipeline.RegisterPlugin` to register 

docs/source/monitoring/index.rst

@@ -7,7 +7,7 @@ Monitoring Internal State
 Heka Reports
 ------------
 
-Heka can emit metrics about it's internal state to either an outgoing Heka
+Heka can emit metrics about its internal state to either an outgoing Heka
 message (and, through the DashboardOutput, to a web dashboard) or to stdout.
 Sending SIGUSR1 to hekad on a UNIX will send a plain text report to stdout. On
 Windows, you will need to send signal 10 to the hekad process using Powershell.

docs/source/pluginconfig/logstreamer.rst

@@ -47,7 +47,7 @@ This is the basic use-case where a single logfile should be read that the
 system may rotate/truncate at some time (hopefully not using truncation though
 that condition is handled). Log rotation inherently has a risk that some
 loglines written may be missed if the program reading the log happens to die
-at exactly the wrong time that the rotation is occuring.
+at exactly the wrong time that the rotation is occurring.
 
 An example of a single rotating logfile would be the case where you
 want to watch /var/log/system.log for all new entries. Here's what the

docs/source/sandbox/development.rst

@@ -6,7 +6,7 @@ Sandbox Development
 Decoders
 --------
 Since decoders cannot be dynamically loaded and they stop Heka processing on
-fatal errors they must be developed outside of a production enviroment. Most
+fatal errors they must be developed outside of a production environment. Most
 Lua  decoders are LPeg based as it is the best way to parse and transform data
 within the sandbox. The other alternatives are the built-in Lua pattern
 matcher or the  JSON parser with a manual transformation.
@@ -33,7 +33,7 @@ matcher or the  JSON parser with a manual transformation.
         [SandboxDecoder]
         filename = "decoder.lua"
 
-4. Configure the DasboardOutput for visibility into the decoder (performance,
+4. Configure the DashboardOutput for visibility into the decoder (performance,
    memory usage, messages processed/failed, etc.)
 
     .. code-block:: ini
@@ -102,15 +102,15 @@ production with live data.
        usually straight forward to correct and commonly caused by a syntax
        error in the script or invalid assumptions about the data (e.g. `cnt =
        cnt + read_message("Fields[counter]")` will fail if the counter field
-       doesn't exist or is non-numeric due to a error in the data).
+       doesn't exist or is non-numeric due to an error in the data).
 
     2. No termination report and the output does not match expectations. These
        are usually a little harder to debug.
 
-        1. Check the Heka dasboard to make sure the router is sending messages
+        1. Check the Heka dashboard to make sure the router is sending messages
            to the plugin. If not, verify your message_matcher configuration.
 
-        2. Visually review the the plugin for errors. Are the message field
+        2. Visually review the plugin for errors. Are the message field
            names correct, was the result of the cjson.decode tested, are the
            output variables actually being assigned to and output/injected,
            etc.

docs/source/sandbox/lua.rst

@@ -138,7 +138,7 @@ Heka specific functions that are exposed to the Lua sandbox
         - representation (string) only used in combination with the Fields variableName
             - representation tag to set
         - fieldIndex (unsigned) only used in combination with the Fields variableName
-            - use to set a specfic instance of a repeated field _name_
+            - use to set a specific instance of a repeated field _name_
         - arrayIndex (unsigned) only used in combination with the Fields variableName
             - use to set a specific element of a field containing an array
 

docs/source/tls.rst

@@ -81,7 +81,7 @@ TLS configuration settings
 	<http://tools.ietf.org/search/rfc5077>`_. If left empty, it will be filled
 	with random data before the first server handshake.
 - min_version (string, both):
-	Specifies the mininum acceptable SSL/TLS version. Must
+	Specifies the minimum acceptable SSL/TLS version. Must
 	be one of the following values:
 
 	- SSL30
@@ -103,13 +103,13 @@ TLS configuration settings
 	Defaults to TLS12.
 
 - client_cafile (string, server):
-	File for server to authenticate client TLS handshake. Any client certs recieved by server
+	File for server to authenticate client TLS handshake. Any client certs received by server
 	must be chained to a CA found in this PEM file.
 
 	Has no effect when NoClientCert is set.
 
 - root_cafile (string, client):
-	File for client to authenticate server TLS handshake. Any server certs recieved by client
+	File for client to authenticate server TLS handshake. Any server certs received by client
 	must be must be chained to a CA found in this PEM file.
 
 Sample TLS configuration