고정 헤더 영역
상세 컨텐츠
본문
- Free Download Manager for Mac. Free Download Manager for Mac is a powerful, easy-to-use and absolutely free download accelerator and manager. Moreover, FDM is 100% safe, open-source software distributed under GPL license.
- Homebrew is a popular package manager for MacOS. RabbitMQ formula is available from Homebrew 's core tap (out of the box). The formula will also install a reasonably recent supported Erlang/OTP version as a dependency.
Overview
RabbitMQ comes with default built-in settings. Those can be entirelysufficient in some environment (e.g. development and QA).For all other cases, as well as production deployment tuning,there is a way to configure many things in the broker as well as plugins.
This guide covers a number of topics related to configuration:
- Different ways in which various settings of the server and plugins are configured
- Configuration file(s): primary rabbitmq.conf and optional advanced.config
- Default configuration file location(s) on various platforms
- Configuration troubleshooting: how to find config file location and inspect and verify effective configuration
- Available core server settings
- Available environment variables
- How to encrypt sensitive configuration values
and more.
For those unfamiliar with it, RabbitMQ is an implementation of the AMQP protocol which is a popular message bus/message queuing system, used for a variety low latency/scalable messaging patterns with advanced routing and publish/subscribe capabilities. Both are open source technologies. Unreal Engine 4 for Mac. Unreal Engine 4 for Mac is a complete suite of game development tools made by game developers, for game developers. From 2D mobile games to console blockbusters and VR, Unreal Engine 4 for Mac gives.
Since configuration affects many areas of the system, including plugins, individual documentation guidesdive deeper into what can be configured. Runtime Tuning is a companion to this guide that focuseson the configurable parameters in the runtime. Production Checklist is a related guidethat outlines what settings will likely need tuning in most production environments.
Means of Configuration
A RabbitMQ node can be configured using a number of mechanisms responsiblefor different areas:
| Mechanism | Description |
| Configuration File(s) | contains server and plugin settings forand so on. |
| Environment Variables | define node name, file and directory locations, runtime flags taken from the shell, or set in the environment configuration file, rabbitmq-env.conf (Linux, MacOS, BSD)and rabbitmq-env-conf.bat (Windows) |
| rabbitmqctl | When internal authentication/authorisation backend is used,rabbitmqctl is the tool that manages virtual hosts, users and permissions. Itis also used to manage runtime parameters and policies. |
| rabbitmq-queues | rabbitmq-queues is the tool that manages settings specific to quorum queues. |
| rabbitmq-plugins | rabbitmq-plugins is the tool that manages plugins. |
| rabbitmq-diagnostics | rabbitmq-diagnostics allows for inspection of node state, including effective configuration,as well as many other metrics and health checks. |
| Parameters and Policies | defines cluster-wide settings which can change at run timeas well as settings that are convenient to configure for groups of queues (exchanges, etc)such as including optional queue arguments. |
| Runtime (Erlang VM) Flags | Control lower-level aspects of the system: memory allocation settings, inter-node communicationbuffer size, runtime scheduler settings and more. |
| Operating System Kernel Limits | Control process limits enforced by the kernel: max open file handle limit,max number of processes and kernel threads, max resident set size and so on. |
Most settings are configured using the first two methods. This guide,therefore, focuses on them.
Configuration File(s)
Introduction
While some settings in RabbitMQ can be tuned using environment variables,most are configured using a main configuration file, usually named rabbitmq.conf.This includes configuration for the core server as well as plugins. An additional configurationfile can be used to configure settings that cannot be expressed in the main file's configurationformat. This is covered in more details below.
The sections below cover the syntax and location of both files,where to find examples, and more.
Config File Locations
Default config file locationsvary between operating systems and package types.
This topic is covered in more detail in the rest of this guide.
When in doubt about RabbitMQ config file location,consult the log file and/or management UI as explained in the following section.
How to Find Config File Location
The active configuration file can be verified by inspecting theRabbitMQ log file. It will show up in the log fileat the top, along with the other broker boot log entries. For example:
If the configuration file cannot be found or read by RabbitMQ, the log entrywill say so:
Alternatively, the location of configuration files used by a local node, use the rabbitmq-diagnostics status command:
and look for the Config files section that would look like this:
To inspect the locations of a specific node, including nodes running remotely, use the -n (short for --node) switch:
Finally, config file location can be found in the management UI,together with other details about nodes.
When troubleshooting configuration settings, it is very useful to verify that the config filepath is correct, exists and can be loaded (e.g. the file is readable) before verifying effective node configuration.Together, these steps help quickly narrow down most common misconfiguration problems.
The New and Old Config File Formats
All supported RabbitMQ versions use an ini-like, sysctl configuration file formatfor the main configuration file. The file is typically named rabbitmq.conf.
The new config format is much simpler, easier for humans to readand machines to generate. It is also relatively limited comparedto the classic config format used prior to RabbitMQ 3.7.0.For example, when configuring LDAP support, it may be necessary to use deeply nested data structures toexpress desired configuration.
To accommodate this need, modern RabbitMQ versions allow for both formats to be used at the same timein separate files: rabbitmq.conf uses the new style format and is recommended for most settings,and advanced.config covers more advanced settings that the ini-style configurationcannot express. This is covered in more detail in the following sections.
| Configuration File | Format Used | Purpose |
| rabbitmq.conf | New style format (sysctl or ini-like) | Primary configuration file. Should be used for most settings.It is easier for humans to read and machines (deployment tools) to generate.Not every setting can be expressed in this format. |
| advanced.config | Classic (Erlang terms) | A limited number of settings that cannot be expressedin the new style configuration format, such as LDAP queries.Only should be used when necessary. |
| rabbitmq-env.conf (rabbitmq-env.conf.bat on Windows) | Environment variable pairs | Used to set environment variables relevant to RabbitMQ in one place. |
Compare this examplary rabbitmq.conf file
to
The Main Configuration File, rabbitmq.conf
The configuration file rabbitmq.confallows the RabbitMQ server and plugins to be configured.Starting with RabbitMQ 3.7.0, the format is in the sysctl format.
The syntax can be briefly explained in 3 lines:
- One setting uses one line
- Lines are structured Key = Value
- Any line starting with a # character is a comment
A minimalistic example configuration file follows:
The same example in the classic config format:
This example will alter the port RabbitMQ listens on forAMQP 0-9-1 and AMQP 1.0 client connections from 5672 to 5673.
The RabbitMQ server source repository contains an example rabbitmq.conf filenamed rabbitmq.conf.example. It contains examples ofmost of the configuration items you might want to set (with some very obscure ones omitted), along withdocumentation for those settings.
Documentation guides such as Networking, TLS, orAccess Control contain many examples in relevant formats.
Note that this configuration file is not to be confused with the environment variableconfiguration files, rabbitmq-env.confand rabbitmq-env-conf.bat.
To override the main RabbitMQ config file location, use the RABBITMQ_CONFIG_FILEenvironment variable. Use .conf as file extensionfor the new style config format, e.g. /etc/rabbitmq/rabbitmq.conf or/data/configuration/rabbitmq/rabbitmq.conf
The advanced.config File
Some configuration settings are not possible or are difficult to configureusing the sysctl format. As such, it is possible to use an additionalconfig file in the Erlang term format (same as rabbitmq.config).That file is commonly named advanced.config. It will be mergedwith the configuration provided in rabbitmq.conf.
The RabbitMQ server source repository contains an example advanced.config filenamed advanced.config.example. It focuses on the options that are typically set using the advanced config.
To override the advanced config file location, use the RABBITMQ_ADVANCED_CONFIG_FILEenvironment variable.
Location of rabbitmq.conf, advanced.config and rabbitmq-env.conf
Default configuration file location is distribution-specific. RabbitMQ packages or nodes will not createany configuration files. Users and deployment tool should use the following locations when creating the files:
| Platform | Default Configuration File Directory | Example Configuration File Paths |
| Generic binary package | $RABBITMQ_HOME/etc/rabbitmq/ | $RABBITMQ_HOME/etc/rabbitmq/rabbitmq.conf,$RABBITMQ_HOME/etc/rabbitmq/advanced.config |
| Debian and Ubuntu | /etc/rabbitmq/ | /etc/rabbitmq/rabbitmq.conf,/etc/rabbitmq/advanced.config |
| RPM-based Linux | /etc/rabbitmq/ | /etc/rabbitmq/rabbitmq.conf,/etc/rabbitmq/advanced.config |
| Windows | %APPDATA%RabbitMQ | %APPDATA%RabbitMQrabbitmq.conf,%APPDATA%RabbitMQadvanced.config |
| MacOS Homebrew Formula | ${install_prefix}/etc/rabbitmq/,and the Homebrew cellar prefix is usually /usr/local | ${install_prefix}/etc/rabbitmq/rabbitmq.conf,${install_prefix}/etc/rabbitmq/advanced.config |
Environment variables can be used to override the location of the configuration file:
When Will Configuration File Changes Be Applied
rabbitmq.conf and advanced.config changes take effect after a node restart.
If rabbitmq-env.conf doesn't exist, it can be created manuallyin the location specified by the RABBITMQ_CONF_ENV_FILE variable.On Windows systems, it is named rabbitmq-env-conf.bat.
Windows service users will need to re-install the service ifconfiguration file location or any values in `rabbitmq-env-conf.bat have changed.Environment variables used by the service would not be updated otherwise.
In the context of deployment automation this means that environment variablessuch as RABBITMQ_BASE and RABBITMQ_CONFIG_FILE should ideally be set before RabbitMQ is installed.This would help avoid unnecessary confusion and Windows service re-installations.
How to Inspect and Verify Effective Configuration of a Running Node
It is possible to print effective configuration (user provided values from all configuration files merged into defaults) usingthe rabbitmq-diagnostics environment command:
to check effective configuration of a specific node, including nodes running remotely, use the -n (short for --node) switch:
The command above will print applied configuration for every application (RabbitMQ, plugins, libraries) running on the node.Effective configuration is computed using the following steps:
- rabbitmq.conf is translated into the internally used (advanced) config format. These configuration is merged into the defaults
- advanced.config is loaded if present, and merged into the result of the step above
Effective configuration should be verified together with config file location.Together, these steps help quickly narrow down most common misconfiguration problems.
The rabbitmq.config (Classic Format) File
Prior to RabbitMQ 3.7.0, RabbitMQ config file was namedrabbitmq.config and used the same Erlang term format used by advanced.config today.That format is still supported for backwards compatibility.
The classic format is deprecated. Please prefer the new style config formatin rabbitmq.conf accompanied by an advanced.config file as needed.
To use a config file in the classic format, export RABBITMQ_CONFIG_FILE to point to the file witha .config extension. The extension will indicate to RabbitMQ that it should treat the file as onein the classic config format.
An example configuration file namedrabbitmq.config.example. It contains an example of most of the configuration items in the classic config format.
To override the main RabbitMQ config file location, use the RABBITMQ_CONFIG_FILEenvironment variable. Use .config as file extensionfor the classic config format.
The use of classic config format should only be limited to the advanced.config file and settingsthat cannot be configured using the ini-style config file.
Example Configuration Files
The RabbitMQ server source repository containsexamples for the configuration files:
These files contain examples of most of the configuration keys along with a brief explanationfor those settings. All configuration items are commented out in theexample, so you can uncomment what you need. Note that theexample files are meant to be used as, well, examples, andshould not be treated as a general recommendation.
In most distributions the example file is placed into thesame location as the real file should be placed (seeabove). On Debian and RPM distributionspolicy forbids doing so; instead find the fileunder /usr/share/doc/rabbitmq-server/or /usr/share/doc/rabbitmq-server-3.8.9/,respectively.
Core Server Variables Configurable in rabbitmq.conf
These variables are the most common. The list is not complete, assome settings are quite obscure.
| Key | Documentation |
|---|---|
| listeners | Ports or hostname/pair on which to listen for 'plain' AMQP 0-9-1 and AMQP 1.0 connections(without TLS). See the Networking guide for moredetails and examples. Default: |
| num_acceptors.tcp | Number of Erlang processes that will accept connections for the TCPlisteners. Default: |
| handshake_timeout | Maximum time for AMQP 0-9-1 handshake (after socket connection and TLS handshake),in milliseconds. Default: |
| listeners.ssl | Ports or hostname/pair on which to listen for TLS-enabled AMQP 0-9-1 and AMQP 1.0 connections.See the TLS guide for moredetails and examples. Default: none (not set) |
| num_acceptors.ssl | Number of Erlang processes that will accept TLS connections from clients. Default: |
| ssl_options | TLS configuration. See the TLS guide. Default: |
| ssl_handshake_timeout | TLS handshake timeout, in milliseconds. Default: |
| vm_memory_high_watermark | Memory threshold at which the flow control istriggered. Can be absolute or relative to the amount of RAM availableto the OS:See the memory-based flowcontrol and alarmsdocumentation. Default: |
| vm_memory_calculation_strategy | Strategy for memory usage reporting. Can be one of the following:
Default: |
| vm_memory_high_watermark_paging_ratio | Fraction of the high watermark limit at which queuesstart to page messages out to disc to free upmemory. See the memory-based flow control documentation. Default: |
| total_memory_available_override_value | Makes it possible to override the total amount of memoryavailable, as opposed to inferring it from the environment usingOS-specific means. This should only be used when actualmaximum amount of RAM available to the node doesn't match the valuethat will be inferred by the node, e.g. due to containerization or similarconstraints the node cannot be aware of. The value may beset to an integer number of bytes or, alternatively, ininformation units (e.g `8GB`). For example,when the value is set to 4 GB, the node will believe it isrunning on a machine with 4 GB of RAM. Default: undefined (not set or used). |
| disk_free_limit | Disk free space limit of the partition on which RabbitMQis storing data. When available disk space falls belowthis limit, flow control is triggered. The value can beset relative to the total amount of RAM or as an absolute valuein bytes or, alternatively, ininformation units (e.g `50MB` or `5GB`):By default free disk space must exceed 50MB. See the Disk Alarms documentation. Default: |
| log.file.level | Controls the granularity of logging. The value is a listof log event category and log level pairs. The level can be one of error (only errors arelogged), warning (only errors and warning arelogged), info (errors, warnings and informationalmessages are logged), or debug (errors, warnings,informational messages and debugging messages arelogged). Default: |
| channel_max | Maximum permissible number of channels tonegotiate with clients, not including a special channel number 0 used in the protocol.Setting to 0 means 'unlimited', a dangerous value since applications sometimes have channel leaks.Using more channels increases memory footprint of the broker. Default: |
| channel_operation_timeout | Channel operation timeout in milliseconds (used internally, not directlyexposed to clients due to messaging protocol differences and limitations). Default: |
| max_message_size | The largest allowed message payload size in bytes. Messagesof larger size will be rejected with a suitable channel exception. Default: 134217728 Max value: 536870912 |
| heartbeat | Value representing the heartbeat timeout suggested by the server duringconnection parameter negotiation.If set to 0 on both ends, heartbeats are disabled (this is not recommended).See the Heartbeats guide for details. Default: |
| default_vhost | Virtual host to create when RabbitMQ creates a newdatabase from scratch. Theexchange `amq.rabbitmq.log` will exist inthis virtual host. Default: |
| default_user | User name to create when RabbitMQ creates a new databasefrom scratch. Default: |
| default_pass | Password for the default user. Default: |
| default_user_tags | Tags for the default user. Default: |
| default_permissions | Permissionsto assign to the default user when creating it. Default: |
| loopback_users | List of users which are only permitted to connect to thebroker via a loopback interface (i.e. `localhost`). To allow the default `guest`user to connect remotely (a security practice unsuitable for production use),set this to `none`: To restrict another user to localhost-only connections,do it like so (`monitoring` is the name of the user): Default: |
| cluster_formation.classic_config.nodes | Classic peer discovery backend's list of nodes to contact.For example, to cluster with nodes `rabbit@hostname1` and `rabbit@hostname2` on first boot: Default: `none` (not set) |
| collect_statistics | Statistics collection mode. Primarily relevant for themanagement plugin. Options are:
Default: |
| collect_statistics_interval | Statistics collection interval inmilliseconds. Primarily relevant forthe managementplugin. Default: |
| management_db_cache_multiplier | Affects the amount of time the management pluginwill cache expensive management queries such asqueue listings. The cache will multiply the elapsed time ofthe last query by this value and cache the result forthis amount of time. Default: |
| auth_mechanisms | SASL authenticationmechanisms to offer to clients. Default: |
| auth_backends | List of authentication and authorisation backends touse. See the access control guide for details and examples. Other databasesthan `rabbit_auth_backend_internal` areavailable through plugins. Default: |
| reverse_dns_lookups | Set to `true` to have RabbitMQ perform areverse DNS lookup on client connections, and presentthat information through `rabbitmqctl` andthe management plugin. Default: |
| delegate_count | Number of delegate processes to use for intra-clustercommunication. On a machine which has a very largenumber of cores and is also part of a cluster, you maywish to increase this value. Default: |
| tcp_listen_options | Default socket options. You probably don't want tochange this. Default: |
| hipe_compile | Do not use. This option is no longer supported. HiPE supported has beendropped starting with Erlang 22. Default: |
| cluster_partition_handling | How to handle network partitions. Available modes are:
Default: |
| cluster_keepalive_interval | How frequently nodes should send keepalive messages toother nodes (in milliseconds). Note that this is not thesame thing as net_ticktime;missed keepalive messages will not cause nodes to beconsidered down. Default: |
| queue_index_embed_msgs_below | Size in bytes of message below which messages willbe embedded directly in the queue index. You are advisedto read the persistertuning documentation before changing this. Default: |
| mnesia_table_loading_retry_timeout | Timeout used when waiting for Mnesia tables in a cluster tobecome available. Default: |
| mnesia_table_loading_retry_limit | Retries when waiting for Mnesia tables in the cluster startup. Note thatthis setting is not applied to Mnesia upgrades or node deletions. Default: |
| mirroring_sync_batch_size | Batch size used to transfer messages to an unsynchronised replica (queue mirror).See documentation on eager batch synchronization. Default: |
| queue_master_locator | Queue master location strategy. Available strategies are:
Default: |
| proxy_protocol | If set to true, RabbitMQ will expect a proxyprotocol header to be sent first when an AMQPconnection is opened. This implies to set up a proxyprotocol-compliant reverse proxy (e.g. HAproxyor AWSELB) in front of RabbitMQ. Clients can't directlyconnect to RabbitMQ when proxy protocol is enabled, soall connections must go through the reverse proxy. See thenetworking guide for more information. Default: |
| cluster_name | Operator-controlled cluster name. This name is used to identify a cluster, and bythe federation and Shovel plugins to record the origin or path of transferred messages.Can be set to any arbitrary string to help identify the cluster (eg. london).This name can be inspected by AMQP 0-9-1 clients in the server properties map. Default: by default the name is derived from the first (seed) node in the cluster. |
The following configuration settings can be set inthe advanced config file only,under the rabbit section.
| Key | Documentation |
|---|---|
| msg_store_index_module | Implementation module for queue indexing. You areadvised to read the message store tuningdocumentation before changing this. Default: rabbit_msg_store_ets_index |
| backing_queue_module | Implementation module for queue contents. Default: |
| msg_store_file_size_limit | Message store segment file size. Changing this for a nodewith an existing (initialised) database is dangerous canlead to data loss! Default: 16777216 |
| trace_vhosts | Used internally bythe tracer. You shouldn'tchange this. Default: |
| msg_store_credit_disc_bound | The credits that a queue process is given by the message store. By default, a queue process is given 4000 message store credits, and then 800 for every 800 messages that it processes. Messages which need to be paged out due to memory pressure will also use this credit. The Message Store is the last component in the credit flow chain. Learn about credit flow. This value only takes effect when messages are persisted to the message store.If messages are embedded on the queue index, then modifying this setting has no effect because credit_flow is NOT used when writing to the queue index. Default: |
| queue_index_max_journal_entries | After how many queue index journal entries it will beflushed to disk. Default: |
| lazy_queue_explicit_gc_run_operation_threshold | Tunable value only for lazy queues when under memory pressure.This is the threshold at which the garbage collector and other memory reduction activities are triggered.A low value could reduce performance, and a high one can improve performance, but cause higher memory consumption.You almost certainly should not change this. Default: |
| queue_explicit_gc_run_operation_threshold | Tunable value only for normal queues when under memory pressure.This is the threshold at which the garbage collector and other memory reduction activities are triggered.A low value could reduce performance, and a high one can improve performance, but cause higher memory consumption.You almost certainly should not change this. Default: |
Several plugins that ship with RabbitMQ havededicated documentation guides that cover plugin configuration:
Configuration Value Encryption
Sensitive configuration entries (e.g. password, URL containingcredentials) can be encrypted in the RabbitMQ configuration file.The broker decrypts encrypted entries on start.
Note that encrypted configuration entries don't make thesystem meaningfully more secure. Nevertheless, theyallow deployments of RabbitMQ to conform toregulations in various countries requiringthat no sensitive data should appear in plain textin configuration files.
Encrypted values must be inside an Erlang encryptedtuple: {encrypted, ...}.Here is an example of a configuration file with an encrypted passwordfor the default user:
Note the config_entry_decoder key with the passphrasethat RabbitMQ will use to decrypt encrypted values.
The passphrase doesn't have to be hardcoded in the configuration file,it can be in a separate file:
RabbitMQ can also request an operator to enter the passphrasewhen it starts by using {passphrase, prompt}.
Use rabbitmqctl and the encodecommand to encrypt values:
Or, on Windows:
Add the decode command if you want to decrypt values:
Or, on Windows:
Values of different types can be encoded. The example above encodesboth binaries (<<'guest'>>) and strings('amqp://fred:secret@host1.domain/my_vhost').
The encryption mechanism uses PBKDF2 to produce a derived keyfrom the passphrase. The default hash function is SHA512and the default number of iterations is 1000. The defaultcipher is AES 256 CBC.
These defaults can be changed in the configuration file:
Or using CLI tools:
Or, on Windows:
Configuration Using Environment Variables
Certain server parameters can be configured using environment variables:node name, RabbitMQ configuration file location,inter-node communication ports, Erlang VM flags, and so on.
Path and Directory Name Restrictions
Some of the environment variable configure paths and locations (node's base or data directory, plugin source and expansion directories,and so on). Those paths have must exclude a number of characters:
- * and ? (on Linux, macOS, BSD and other UNIX-like systems)
- ^ and ! (on Windows)
- [ and ]
- { and }
The above characters will render the node unable to start or function as expected (e.g. expand plugins and load their metadata).
Linux, MacOS, BSD
On UNIX-based systems (Linux, MacOS and flavours of BSD) it is possible touse a file named rabbitmq-env.confto define environment variables that will be used by the broker.Its location is configurableusing the RABBITMQ_CONF_ENV_FILE environment variable.
rabbitmq-env.conf uses the standard environment variable namesbut without the RABBITMQ_ prefix. For example, theRABBITMQ_CONFIG_FILE variable appears below as CONFIG_FILE andRABBITMQ_NODENAME becomes NODENAME:
Rabbitmq Server Download
See the rabbitmq-env.conf man page for details.
Windows
The easiest option to customise names, ports or locations isto configure environment variables in the Windows dialogue:Start > Settings > Control Panel > System > Advanced > Environment Variables.Then create or edit the system variable name and value.
Alternatively it is possible to use a file named rabbitmq-env-conf.batto define environment variables that will be used by the broker.Its location is configurableusing the RABBITMQ_CONF_ENV_FILE environment variable.
Windows service users will need to re-install the service if configuration file locationor any values in `rabbitmq-env-conf.bat changed. Environment variables used bythe service would not be updated otherwise.
This can be done using the installer or on the command linewith administrator permissions:
- Start an administrative command prompt
- cd into the sbin folder under the RabbitMQ server installation directory (such as C:Program Files (x86)RabbitMQ Serverrabbitmq_server-{version}sbin)
- Run rabbitmq-service.bat stop to stop the service
- Run rabbitmq-service.bat remove to remove the Windows service (this will not remove RabbitMQ or its data directory)
- Set environment variables via command line, i.e. run commands like the following:
- Run rabbitmq-service.bat install
- Run rabbitmq-service.bat start
This will restart the node in a way that makes the environment variable andrabbitmq-env-conf.bat changes to be observable to it.
Environment Variables Used by RabbitMQ
All environment variables used by RabbitMQ use theprefix RABBITMQ_ (except when defined in rabbitmq-env.conf orrabbitmq-env-conf.bat).
Environment variables set in the shell environment takepriority over those setin rabbitmq-env.conf orrabbitmq-env-conf.bat, which in turn overrideRabbitMQ built-in defaults.
The table below describes key environment variables that can be used to configure RabbitMQ.More variables are covered in the File and Directory Locations guide.
| Name | Description |
|---|---|
| RABBITMQ_NODE_IP_ADDRESS | Change this if you only want to bind to one network interface.Binding to two or more interfaces can be set up in the configuration file. Default: an empty string, meaning 'bind to all network interfaces'. |
| RABBITMQ_NODE_PORT | See Networking guide for more information on ports used by variousparts of RabbitMQ. Default: 5672. |
| RABBITMQ_DIST_PORT | Port used for inter-node and CLI tool communication. Ignored if node configfile sets kernel.inet_dist_listen_min orkernel.inet_dist_listen_max keys.See Networking for details. Default: RABBITMQ_NODE_PORT + 20000 |
| ERL_EPMD_ADDRESS | Interface(s) used by epmd, a component in inter-node and CLI tool communication. Default: all available interfaces, both IPv6 and IPv4. |
| ERL_EPMD_PORT | Port used by epmd, a component in inter-node and CLI tool communication. Default: 4369 |
| RABBITMQ_DISTRIBUTION_BUFFER_SIZE | Outgoing data buffer size limitto use for inter-node communication connections, in kilobytes. Values lower than64 MB are not recommended. Default: 128000 |
| RABBITMQ_NODENAME | The node name should be unique per Erlang-node-and-machine combination.To run multiple nodes, see the clustering guide. Default:
|
| RABBITMQ_CONFIG_FILE | Main RabbitMQ config file path, for example,/etc/rabbitmq/rabbitmq.conf or /data/configuration/rabbitmq.conf for new style configuration format files.If classic config format it used, the extension must be .config Default:
|
| RABBITMQ_ADVANCED_CONFIG_FILE | 'Advanced' (Erlang term-based) RabbitMQ config file path with a .config file extension.For example, /data/rabbitmq/advanced.config. Default:
|
| RABBITMQ_CONF_ENV_FILE | Location of the file that contains environment variable definitions (without the RABBITMQ_prefix). Note that the file name on Windows is different from other operating systems. Default:
|
| RABBITMQ_MNESIA_BASE | This base directory contains sub-directories for the RabbitMQserver's node database, message store and cluster state files, one for each node,unless RABBITMQ_MNESIA_DIR is set explicitly.It is important that effective RabbitMQ user has sufficient permissionsto read, write and create files and subdirectories in this directoryat any time. This variable is typically not overridden.Usually RABBITMQ_MNESIA_DIR is overridden instead. Default:
|
| RABBITMQ_MNESIA_DIR | The directory where this RabbitMQ node's data is stored. This includesa schema database, message stores, cluster member information and otherpersistent node state. Default:
|
| RABBITMQ_PLUGINS_DIR | The list of directories where plugin archive files are located and extractedfrom. This is PATH-like variable, wheredifferent paths are separated by an OS-specific separator(: for Unix, ; for Windows).Plugins can be installed to any of the directories listed here.Must not contain any characters mentioned in the path restriction section. Default:
|
| RABBITMQ_PLUGINS_EXPAND_DIR | The directory the node expand (unpack) plugins to and use it as a code path location.Must not contain any characters mentioned in the path restriction section. Default:
|
| RABBITMQ_USE_LONGNAME | When set to true this will cause RabbitMQto use fully qualified names to identify nodes. Thismay prove useful in environments that use fully-qualified domain names.Note that it is not possible to switch between using short and long names withoutresetting the node. Default: false |
| RABBITMQ_SERVICENAME | The name of the installed Windows service. This will appear inservices.msc. Default: RabbitMQ. |
| RABBITMQ_CONSOLE_LOG | Set this variable to new or reuseto redirect console output from the server to a file named%RABBITMQ_SERVICENAME% in thedefault RABBITMQ_BASE directory.
Default: (none) |
| RABBITMQ_SERVER_CODE_PATH | Extra code path (a directory) to be specified when starting the runtime.Will be passed to the erl command when a node is started. Default: (none) |
| RABBITMQ_CTL_ERL_ARGS | Parameters for the erl command used when invokingrabbitmqctl. This could be set to specify a rangeof ports to use for Erlang distribution: -kernel inet_dist_listen_min 35672 -kernel inet_dist_listen_max 35680 Default: (none) |
| RABBITMQ_SERVER_ERL_ARGS | Standard parameters for the erl command used wheninvoking the RabbitMQ Server. This should be overridden fordebugging purposes only. Overriding this variablereplaces the default value. Default:
|
| RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS | Additional parameters for the erl command used wheninvoking the RabbitMQ Server. The value of this variableis appended to the default list of arguments (RABBITMQ_SERVER_ERL_ARGS). Default:
|
| RABBITMQ_SERVER_START_ARGS | Extra parameters for the erl command used wheninvoking the RabbitMQ Server. This will not overrideRABBITMQ_SERVER_ERL_ARGS. Default: (none) |
Besides the variables listed above, there are several environment variables whichtell RabbitMQ where to locate its database, log files, plugins, configuration and so on.
Finally, some environment variables are operating system-specific.
| Name | Description |
|---|---|
| HOSTNAME | The name of the current machine. Default:
|
| COMPUTERNAME | The name of the current machine. Default:
|
| ERLANG_SERVICE_MANAGER_PATH | This path is the location of erlsrv.exe,the Erlang service wrapper script. Default:
|
Operating System Kernel Limits
Most operating systems enforce limits on kernel resources: virtual memory, stack size, open file handlesand more. To Linux users these limits can be known as 'ulimit limits'.
RabbitMQ nodes are most commonly affected by the maximum open file handle limit.Default limit value on most Linux distributions is usually 1024, which is very low for a messaging broker (or generally, any data service).See Production Checklist for recommended values.
Modifying Limits
With systemd (Modern Linux Distributions)
On distributions that use systemd, the OS limits are controlled viaa configuration file at /etc/systemd/system/rabbitmq-server.service.d/limits.conf.For example, to set the max open file handle limit (nofile) to 64000:
See systemd documentation to learn aboutthe supported limits and other directives.
With Docker
To configure kernel limits for Docker contains, use the 'default-ulimits' key inDocker daemon configuration file.The file has to be installed on Docker hosts at /etc/docker/daemon.json:
Without systemd (Older Linux Distributions)
The most straightforward way to adjust the per-user limit forRabbitMQ on distributions that do not use systemd is to edit the /etc/default/rabbitmq-server(provided by the RabbitMQ Debian package) or rabbitmq-env.confto invoke ulimit before the service is started.
This soft limit cannot go higher than the hard limit (which defaults to 4096 in many distributions).The hard limit can be increased via/etc/security/limits.conf. This also requires enabling the pam_limits.so moduleand re-login or reboot.
Note that limits cannot be changed for running OS processes.
Getting Help and Providing Feedback
If you have questions about the contents of this guide orany other topic related to RabbitMQ, don't hesitate to ask themon the RabbitMQ mailing list.
Help Us Improve the Docs <3
If you'd like to contribute an improvement to the site,its source is available on GitHub.Simply fork the repository and submit a pull request. Thank you!
Overview
This guide covers RabbitMQ installation on Windows. It focuses on the two recommended installationoptions:
- Using the official installer as an administrative user
The guide also covers a few post-installation topics in the context of Windows:
- The basics of node configuration
- Firewall and security tools effects
and more. These topics are covered in more details in the rest of documentation guides.
A separate companion guide covers known Windows-specific issuesand ways to mitigate them.
Using chocolatey
RabbitMQ packages are distributed via Chocolatey.New releases can take a while (sometimes weeks) to get through approvals,so this option is not guaranteed to provide the latest release.It does, however, manage the required dependencies.
To install RabbitMQ using Chocolatey, run the following command from the command line or from PowerShell:
For many use cases, Chocolatey is the optimal installation method.
The Chocolatey RabbitMQ package is open source and can be found on GitHub.
Using the Installer
The official RabbitMQ installer is produced for every RabbitMQ release.
Compared to installation via Chocolatey, this option gives Windows usersthe most flexibility but also requires them to beaware of certain assumptions and requirements in the installer:
- There must be only one Erlang version installed at a time
- Erlang must be installed using an administrative account
- It is highly recommended that RabbitMQ is also installed as an administrative account
- Installation path must only contain ASCII characters
- It may be necessary to manually copy the shared secret file used by CLI tools
- CLI tools require Windows console to operate in UTF-8 mode
When these conditions are not met, Windows service and CLI tools may requirereinstallation or other manual steps to get them to function as expected.
This is covered in more detail in the Windows-specific Issues guide.
Dependencies
RabbitMQ requires a 64-bit supported version of Erlang for Windows to be installed.Latest binary builds for Windows can be obtained from the Erlang/OTP Version Tree page.
Note that Erlang must be installed using an administrative account or it won't bediscoverable to the RabbitMQ Windows service.
Once a supported version of Erlang is installed, download the RabbitMQ installer, rabbitmq-server-{version}.exeand run it. It installs RabbitMQ as a Windows service and starts it using the default configuration.
Direct Downloads
| Description | Download | Signature |
|---|---|---|
| Installer for Windows systems (from GitHub, recommended) | rabbitmq-server-3.8.9.exe | Signature |
| Alternative download location (from Bintray) | rabbitmq-server-3.8.9.exe |
Run RabbitMQ Windows Service
Once both Erlang and RabbitMQ have been installed, a RabbitMQ node can be started as a Windows service.The RabbitMQ service starts automatically. RabbitMQ Windows serviceca be managed from the Start menu.
CLI Tools
RabbitMQ nodes are often managed, inspected and operated using CLI Toolsin PowerShell.
On Windows, CLI tools have a .bat suffix compared to other platforms. For example,rabbitmqctl on Windows is invoked as rabbitmqctl.bat.CLI tools are primarily covered in the .
In order for these tools to work they must be able to authenticate with RabbitMQ nodesusing a shared secret file called the Erlang cookie.
The main CLI tools guide covers most topics related to command line tool usage.
In order to explore what commands various RabbitMQ CLI tools provide, use the help command:
To learn about a specific command, pass its name as an argument to help:
Cookie File Location
On Windows, the cookie file location depends onwhether the HOMEDRIVE and HOMEPATH environment variables are set.
If RabbitMQ is installed using a non-administrative account, a shared secret fileused by nodes and CLI tools will not be placed into a correct location,leading to authentication failures when rabbitmqctl.batand other CLI tools are used.
One of these options can be used to mitigate:
- Re-install RabbitMQ using an administrative user
- Copy the file .erlang.cookie manually from %SystemRoot% or %SystemRoot%system32configsystemprofileto %HOMEDRIVE%%HOMEPATH%.
Node Configuration
The service starts using its default settings, listeningfor connections on default interfaces and ports.
Node configuration is primarily done using a configuration file.A number of available environment variables can be usedto control node's data location, configuration file path and so on.
This is covered in more detail in the Configuration guide
Environment Variable Changes on Windows
Important: after setting environment variables, it is necessary to re-install the Windows service. Restarting the service will not be sufficient.
Managing a RabbitMQ Node
Managing the Service
Links to RabbitMQ directories can be found in the Start Menu.
There is also a link to a command prompt window thatwill start in the sbin dir, in the Start Menu. This isthe most convenient way to run the command line tools.
Note that CLI tools will have to authenticate to the target RabbitMQ node.
Stopping a Node
To stop the broker or check its status, userabbitmqctl.bat in sbin (as an administrator).
Checking Node Status
The following CLI command runs a basic health checkand displays some information about the node if it is running.
For it to work,two conditions must be true:
- The node must be running
- rabbitmqctl.bat must be able to authenticate with the node
See the CLI tools section and the Monitoring and Health Checks guideto learn more.
Log Files and Management
Singletonchannelpool Rabbitmq
Server logs are critically important in troubleshooting and root cause analysis.See Logging and File and Directory Location guidesto learn about log file location, log rotation and more.
Firewalls and Security Tools
Firewalls and security tools can prevent RabbitMQ Windows service and CLI tools from operatingcorrectly.
Such tools should be configured to whitelist access to ports used by RabbitMQ.
Default User Access
The broker creates a user guest with passwordguest. Unconfigured clients will in general use thesecredentials. By default, these credentials can only beused when connecting to the broker as localhost so youwill need to take action before connecting from any othermachine.
See the documentation on access control for information on how to create more users and deletethe guest user.
Port Access
RabbitMQ nodes bind to ports (open server TCP sockets) in order to accept client and CLI tool connections.Other processes and tools such as anti-virus software may prevent RabbitMQ from binding to a port. When that happens,the node will fail to start.
CLI tools, client libraries and RabbitMQ nodes also open connections (client TCP sockets).Firewalls can prevent nodes and CLI tools from communicating with each other.Make sure the following ports are accessible:
- 4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools
- 5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS
- 25672: used for inter-node and CLI tools communication (Erlang distribution server port)and is allocated from a dynamic range (limited to a single port by default,computed as AMQP port + 20000). Unless external connections on these ports are really necessary (e.g.the cluster uses federation or CLI tools are used on machines outside the subnet),these ports should not be publicly exposed. See networking guide for details.
- 35672-35682: used by CLI tools (Erlang distribution client ports) for communication with nodesand is allocated from a dynamic range (computed as server distribution port + 10000 throughserver distribution port + 10010). See networking guide for details.
- 15672: HTTP API clients, management UI and rabbitmqadmin(only if the management plugin is enabled)
- 61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)
- 1883, 8883: (MQTT clients without and with TLS, if the MQTT plugin is enabled
- 15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)
- 15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)
It is possible to configure RabbitMQto use different ports and specific network interfaces.
Upgrading Erlang VM
If you have an existing installation and are planning to upgradethe Erlang VM from a 32-bit to a 64-bit version then you must uninstallthe broker before upgrading the VM. The installer will not be able to stopor remove a service that was installed with an Erlang VM of a differentarchitecture.
Dump File Location When Running as a Service
In the event that the Erlang VM terminates when RabbitMQ is runningas a service, rather than writing the crash dump to the currentdirectory (which doesn't make sense for a service) it is writtento an erl_crash.dump file in the base directory ofthe RabbitMQ server, defaulting to %APPDATA%%RABBITMQ_SERVICENAME% - typically %APPDATA%RabbitMQ otherwise).
Getting Help and Providing Feedback
If you have questions about the contents of this guide orany other topic related to RabbitMQ, don't hesitate to ask themon the RabbitMQ mailing list.
Help Us Improve the Docs <3
If you'd like to contribute an improvement to the site,its source is available on GitHub.Simply fork the repository and submit a pull request. Thank you!
