Difference between revisions of "Plugin:AMQP"

From collectd Wiki
Jump to: navigation, search
(Exchanges: New section.)
(Routing keys: New section.)
Line 60: Line 60:
  
 
Exchanges are created as ''non-durable'' and ''auto delete''. This means the exchange won't exist after the broker was restarted and will automatically get removed when there are no more queues bound to it.
 
Exchanges are created as ''non-durable'' and ''auto delete''. This means the exchange won't exist after the broker was restarted and will automatically get removed when there are no more queues bound to it.
 +
 +
=== Queues ===
 +
 +
When subscribing, the plugin will automatically create a queue after receiving. If the <code>Queue</code> configuration option has been specified, this name is used, otherwise a unique name is chosen automatically by the broker.
 +
 +
Flags used when creating the queue are ''non-durable'', ''non-exclusive'', ''auto delete''.
 +
 +
=== Bindings ===
 +
 +
If a <code>Exchange</code> configuration option is given in a ''Subscribe'' block, the (possibly newly created) queue will be bound to the given exchange.
 +
 +
=== Routing keys ===
 +
 +
If a ''routing key'' has been configured, the data sent to the broker will always use the given routing key. If no ''routing key'' has been configured in a ''Publish'' block, a routing key will be created from the [[identifier]]. Because a ''routing key'' consists of several fields separated by dots, all dots within the ''identifier'' will be replaced by slashes. For example:
 +
* <code>collectd.example/collectd/org.cpu.0.cpu.idle</code>
 +
* <code>collectd.example/collectd/org.memory..memory.used</code>
 +
 +
The routing key specified in ''Subscribe'' blocks is copied into automatically created bindings. How this ''routing key'' is evaluated depends on the type of exchange the queue is bound to. In case of a ''topic'' exchange, you can use wildcards to select only certain values. The following example requests only [[Plugin:CPU|cpu statistics]] from the exchange:
 +
* <code>collectd.*.cpu.#</code>
  
 
== Dependencies ==
 
== Dependencies ==

Revision as of 09:24, 9 August 2010

AMQP plugin
Type: write
Callbacks: config, shutdown, write
Status: in development
First version: 5.0
Copyright: 2009 Sebastien Pahl
2010 Florian Forster
License: MIT license
Manpage: collectd.conf(5)
List of Plugins

The AMQP plugin transmits or receives values collected by collectd via the Advanced Message Queuing Protocol (AMQP). Data is sent to or received from a "message broker" – a daemon relaying messages. The values are encoded in either the plain text protocol or JSON, though only the plain-text protocol can be parsed by the plugin at the moment. Messages can be sent in either persistent (guaranteed delivery) or transient (higher efficiency but values may be lost) delivery mode.

Synopsis

<Plugin "amqp">
  # Send values to an AMQP broker
  <Publish "some_name">
    Host "localhost"
    Port "5672"
    VHost "/"
    User "guest"
    Password "guest"
    Exchange "amq.fanout"
#   ExchangeType "fanout"
#   RoutingKey "collectd"
#   Persistent false
#   Format "command"
#   StoreRates false
  </Publish>
  
  # Receive values from an AMQP broker (work in progress)
  <Subscribe "some_name">
    Host "localhost"
    Port "5672"
    VHost "/"
    User "guest"
    Password "guest"
    Exchange "amq.fanout"
#   ExchangeType "fanout"
#   Queue "queue_name"
#   RoutingKey "collectd.#"
  </Subscribe>
</Plugin>

Routing

AMQP uses three components to deliver messages from a publisher to a subscriber: Exchanges are the place where publishers post their messages; Queues are the place from where subscribers receive messages. An exchange and a queue may be connected with a binding, meaning that messages may be routed from the exchange to the queue.

Which messages are sent to which queue depends on the type of the exchange and the binding.

  • A fanout exchange sends messages too all queues bound to it.
  • A direct exchange compares the routing keys of the message and the binding and sends the message to the appropriate queue only if they are identical.
  • A topic exchange compares the routing keys of the message and the binding and allows for wildcards (placeholders) in the binding's routing key.
  • A headers exchange matches header fields attached to a message to make a routing decision. Currently the AMQP plugin doesn't support the creation of header fields and can't create appropriate bindings automatically.

Exchanges

The AMQP plugin can automatically create an appropriate exchange after connecting to the broker. This happens if the ExchangeType configuration option has been set.

The type is given as a string which is passed to the broker. Usually this would be one of the standard strings – "direct", "fanout", "topic", or "header" – but the standard explicitly allows for implementation specific types.

Exchanges are created as non-durable and auto delete. This means the exchange won't exist after the broker was restarted and will automatically get removed when there are no more queues bound to it.

Queues

When subscribing, the plugin will automatically create a queue after receiving. If the Queue configuration option has been specified, this name is used, otherwise a unique name is chosen automatically by the broker.

Flags used when creating the queue are non-durable, non-exclusive, auto delete.

Bindings

If a Exchange configuration option is given in a Subscribe block, the (possibly newly created) queue will be bound to the given exchange.

Routing keys

If a routing key has been configured, the data sent to the broker will always use the given routing key. If no routing key has been configured in a Publish block, a routing key will be created from the identifier. Because a routing key consists of several fields separated by dots, all dots within the identifier will be replaced by slashes. For example:

  • collectd.example/collectd/org.cpu.0.cpu.idle
  • collectd.example/collectd/org.memory..memory.used

The routing key specified in Subscribe blocks is copied into automatically created bindings. How this routing key is evaluated depends on the type of exchange the queue is bound to. In case of a topic exchange, you can use wildcards to select only certain values. The following example requests only cpu statistics from the exchange:

  • collectd.*.cpu.#

Dependencies

See also