8ae3332165
- moved and renamed files/folders based on new structure - updated docs navigation based on new structure - moved CLI to top nav (created commands.jsx and commands-navigation.js) - updated and added redirects - updating to be consistent with standalone categories - changing "overview" link in top nav to lead to where intro was moved (docs/intro) - adding redirects for intro content - deleting old intro folders - format all data/navigation files - deleting old commands folder - reverting changes to glossary page - adjust intro navigation for removal of 'vs' paths - add helm page redirect - fix more redirects - add a missing redirect - fix broken anchor links and formatting mistakes - deleted duplicate section, added redirect, changed link - removed duplicate glossary page
63 lines
2.4 KiB
Plaintext
63 lines
2.4 KiB
Plaintext
---
|
|
layout: commands
|
|
page_title: 'Commands: Event'
|
|
sidebar_title: event
|
|
description: >-
|
|
The event command provides a mechanism to fire a custom user event to an
|
|
entire datacenter. These events are opaque to Consul, but they can be used to
|
|
build scripting infrastructure to do automated deploys, restart services, or
|
|
perform any other orchestration action. Events can be handled by using a
|
|
watch.
|
|
---
|
|
|
|
# Consul Event
|
|
|
|
Command: `consul event`
|
|
|
|
The `event` command provides a mechanism to fire a custom user event to an
|
|
entire datacenter. These events are opaque to Consul, but they can be used
|
|
to build scripting infrastructure to do automated deploys, restart services,
|
|
or perform any other orchestration action. Events can be handled by
|
|
[using a watch](/docs/agent/watches).
|
|
|
|
Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip).
|
|
|
|
While the details are not important for using events, an understanding of
|
|
the semantics is useful. The gossip layer will make a best-effort to deliver
|
|
the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is
|
|
replicated using [consensus](/docs/internals/consensus), event data
|
|
is purely peer-to-peer over gossip. This means it is not persisted and does
|
|
not have a total ordering. In practice, this means you cannot rely on the
|
|
order of message delivery. An advantage however is that events can still
|
|
be used even in the absence of server nodes or during an outage.
|
|
|
|
The underlying gossip also sets limits on the size of a user event
|
|
message. It is hard to give an exact number, as it depends on various
|
|
parameters of the event, but the payload should be kept very small
|
|
(< 100 bytes). Specifying too large of an event will return an error.
|
|
|
|
## Usage
|
|
|
|
Usage: `consul event [options] [payload]`
|
|
|
|
The only required option is `-name` which specifies the event name. An optional
|
|
payload can be provided as the final argument.
|
|
|
|
#### API Options
|
|
|
|
@include 'http_api_options_client.mdx'
|
|
|
|
@include 'http_api_options_server.mdx'
|
|
|
|
#### Command Options
|
|
|
|
- `-name` - The name of the event.
|
|
|
|
- `-node` - Regular expression to filter nodes which should evaluate the event.
|
|
|
|
- `-service` - Regular expression to filter to only nodes with matching services.
|
|
|
|
- `-tag` - Regular expression to filter to only nodes with a service that has
|
|
a matching tag. This must be used with `-service`. As an example, you may
|
|
do `-service mysql -tag secondary`.
|