github.com/google/cloudprober@v0.11.3/docs/content/concepts/probe.md (about)

     1  ---
     2  menu:
     3      main:
     4          name: "What is a Probe"
     5          weight: 1
     6  title: "Probe"
     7  date: 2017-07-25T17:24:32-07:00
     8  ---
     9  Cloudprober's main task is to run probes. A probe executes something, usually
    10  against a set of targets, to verify that the systems are working as expected from consumers' point of view. For example, an HTTP probe executes an HTTP request against a web server to verify that the web server is available. Cloudprober probes run repeatedly at a configured interval and export probe results as a set of metrics.
    11  
    12  A probe is defined as a set of the following fields:
    13  
    14   Field        | Description
    15  --------------|---------
    16  `type`          | Probe type, for example: HTTP, PING or UDP
    17  `name`          | Probe name. Each probe should have a unique name.
    18  `interval_msec` | How often to run the probe (in milliseconds).
    19  `timeout_msec`  | Probe timeout (in milliseconds).
    20  `targets`       | Targets to run probe against.
    21  `validator`     | Probe validators, further explained [here](/how-to/validators). 
    22  `<type>_probe`  | Probe type specific configuration. 
    23  
    24  Please take a look at the [ProbeDef protobuf](https://github.com/google/cloudprober/blob/master/probes/proto/config.proto) for further details on various fields and options. All probe types export following metrics at a minimum:
    25  
    26  |Metric | Description|
    27  |-------|------------|
    28  |`total`   | Total number of probes. |
    29  |`success` | Number of successful probes. Deficit between _total_ and _success_ indicates failures.|
    30  |`latency` | Cumulative probe latency (by default in microseconds). Latency can also be configured to be a distribution (histogram) metric through a config option (`latency_distribution`). By default it's just the sum of the latencies observed so far. Average latency can be computed using _rate(latency) / rate(success)_.|
    31  
    32  
    33  ## Probe Types
    34  
    35  Cloudprober has built-in support for the following probe types:
    36  
    37  * [Ping](#ping)
    38  * [HTTP](#http)
    39  * [UDP](#udp)
    40  * [DNS](#dns)
    41  * [External](#external)
    42  
    43  More probe types can be added through cloudprober extensions (to be documented).
    44  
    45  ### Ping
    46  
    47  [`Code`](http://github.com/google/cloudprober/tree/master/probes/ping) | [`Config
    48  options`](http://github.com/google/cloudprober/tree/master/probes/ping/proto/config.proto)
    49  
    50  Ping probe type implements a fast ping prober, that can probe hundreds of
    51  targets in parallel. Probe results are reported as number of packets sent
    52  (total), received (success) and round-trip time (latency). It supports raw
    53  sockets (requires root access) as well as datagram sockets for ICMP (doesn't
    54  require root access).
    55  
    56  ICMP datagram sockets are not enabled by default on most Linux systems. You can
    57  enable them by running the following command:
    58  `sudo sysctl -w net.ipv4.ping_group_range="0 5000"`
    59  
    60  ### HTTP
    61  
    62  [`Code`](http://github.com/google/cloudprober/tree/master/probes/http) | [`Config
    63  options`](http://github.com/google/cloudprober/tree/master/probes/http/proto/config.proto)
    64  
    65  HTTP probe is be used to send HTTP(s) requests to a target and verify that a
    66  response is received. Apart from the core probe metrics (total, success, and
    67  latency), HTTP probes also export a map of response code counts. Requests are
    68  marked as failed if there is a timeout.
    69  
    70  ### UDP
    71  
    72  [`Code`](http://github.com/google/cloudprober/tree/master/probes/udp) | [`Config
    73  options`](http://github.com/google/cloudprober/tree/master/probes/udp/proto/config.proto)
    74  
    75  UDP probe sends a UDP packet to the configured targets. UDP probe (and all
    76  other probes that use ports) provides more coverage for the network elements on
    77  the data path as most packet forwarding elements use 5-tuple hashing and using
    78  a new source port for each probe ensures that we hit different network element
    79  each time.
    80  
    81  ### DNS
    82  
    83  [`Code`](http://github.com/google/cloudprober/tree/master/probes/dns) | [`Config
    84  options`](http://github.com/google/cloudprober/tree/master/probes/dns/proto/config.proto)
    85  
    86  DNS probe type is implemented in a similar way as other probes except for that
    87  it sends DNS requests to the target.
    88  
    89  ### External
    90  
    91  [`Code`](http://github.com/google/cloudprober/tree/master/probes/external) | [`Config
    92  options`](http://github.com/google/cloudprober/tree/master/probes/external/proto/config.proto)
    93  
    94  External probe type allows running arbitrary probes through cloudprober. For an
    95  external probe, actual probe logic resides in an external program; cloudprober
    96  only manages the execution of that program and provides a way to export that
    97  data through the standard channel.
    98  
    99  External probe can be configured in two modes:
   100  
   101  *  __ONCE__:
   102     In this mode, an external program is executed for each probe run. Exit
   103     status of the program determines the success or failure of the probe.
   104     External probe can optionally be configured to interpret external program's
   105     output as metrics. This is a simple model but it doesn't allow the external
   106     program to maintain state and multiple forks can be expensive depending on
   107     the frequency of the probes.
   108  
   109  *  __SERVER__:
   110     In this mode, external program is expected to run in server mode. Cloudprober
   111     automatically starts the external program if it's not running at the time of
   112     the probe execution. Cloudprober and external probe process communicate with
   113     each other over stdin/stdout using protobuf messages defined in
   114     [probes/external/proto/server.proto](https://github.com/google/cloudprober/blob/master/probes/external/proto/server.proto).