The configuration remains the same for the end-user. The only exception
is the log root directory: it is now set through the `log_root`
application env. variable in `rabbit`. People using the Cuttlefish-based
configuration file are not affected by this exception.
The main change is how the logging facility is configured. It now
happens in `rabbit_prelaunch_logging`. The `rabbit_lager` module is
removed.
The supported outputs remain the same: the console, text files, the
`amq.rabbitmq.log` exchange and syslog.
The message text format slightly changed: the timestamp is more precise
(now to the microsecond) and the level can be abbreviated to always be
4-character long to align all messages and improve readability. Here is
an example:
2021-03-03 10:22:30.377392+01:00 [dbug] <0.229.0> == Prelaunch DONE ==
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0>
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Starting RabbitMQ 3.8.10+115.g071f3fb on Erlang 23.2.5
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com
The example above also shows that multiline messages are supported and
each line is prepended with the same prefix (the timestamp, the level
and the Erlang process PID).
JSON is also supported as a message format and now for any outputs.
Indeed, it is possible to use it with e.g. syslog or the exchange. Here
is an example of a JSON-formatted message sent to syslog:
Mar 3 11:23:06 localhost rabbitmq-server[27908] <0.229.0> - {"time":"2021-03-03T11:23:06.998466+01:00","level":"notice","msg":"Logging: configured log handlers are now ACTIVE","meta":{"domain":"rabbitmq.prelaunch","file":"src/rabbit_prelaunch_logging.erl","gl":"<0.228.0>","line":311,"mfa":["rabbit_prelaunch_logging","configure_logger",1],"pid":"<0.229.0>"}}
For quick testing, the values accepted by the `$RABBITMQ_LOGS`
environment variables were extended:
* `-` still means stdout
* `-stderr` means stderr
* `syslog:` means syslog on localhost
* `exchange:` means logging to `amq.rabbitmq.log`
`$RABBITMQ_LOG` was also extended. It now accepts a `+json` modifier (in
addition to the existing `+color` one). With that modifier, messages are
formatted as JSON intead of plain text.
The `rabbitmqctl rotate_logs` command is deprecated. The reason is
Logger does not expose a function to force log rotation. However, it
will detect when a file was rotated by an external tool.
From a developer point of view, the old `rabbit_log*` API remains
supported, though it is now deprecated. It is implemented as regular
modules: there is no `parse_transform` involved anymore.
In the code, it is recommended to use the new Logger macros. For
instance, `?LOG_INFO(Format, Args)`. If possible, messages should be
augmented with some metadata. For instance (note the map after the
message):
?LOG_NOTICE("Logging: switching to configured handler(s); following "
"messages may not be visible in this log output",
#{domain => ?RMQLOG_DOMAIN_PRELAUNCH}),
Domains in Erlang Logger parlance are the way to categorize messages.
Some predefined domains, matching previous categories, are currently
defined in `rabbit_common/include/logging.hrl` or headers in the
relevant plugins for plugin-specific categories.
At this point, very few messages have been converted from the old
`rabbit_log*` API to the new macros. It can be done gradually when
working on a particular module or logging.
The Erlang builtin console/file handler, `logger_std_h`, has been forked
because it lacks date-based file rotation. The configuration of
date-based rotation is identical to Lager. Once the dust has settled for
this feature, the goal is to submit it upstream for inclusion in Erlang.
The forked module is calld `rabbit_logger_std_h` and is based
`logger_std_h` in Erlang 23.0.
... when no Mnesia directory is specified. The reason is that the
default behavior changed: if the node is unavailable and no Mnesia
directory is configured, we use the default directory.
Not directly related to rabbitmq/rabbitmq-server#2321
but useful on its own. We've had requests for and discussions
about such commands in the past and now that Ranch supports
listener suspension, there aren't many reasons not to do it.
Currently we have a --auto-complete magic argument which
does not show up in `help` and requires its argument to be
explcitly -- separated from the actual flag, which is
counter-intuitive.
This introduces a new autocomplete command which is delegated
to by --auto-complete, much like --help is simply a special
way of invoking the `help` command.
Closes#439
for evaluation of scripts in environments where standard input
redirection is not an option or problematic, e.g.
certain Windows environments.
Closes#438
* `help` printed an "Error:" at the top for no reason
* `help [command]` with a non-existent command did not offer a suggestion
like an attempt to invoke a non-existent command would
* Exit codes were not consistent
* `help --list-commands` had line break issues
With this change,
* `help` is consistent with --help
* `help [command]` is consistent with `[command] --help`
* If a command is not found, either during the execution flow
or `help [commnad]`, we consistently attempt a Jaro distance suggestion
* Successful or effectively successful exits from the `help`
command do not produce any error messages at the top
HiPE has been deprecated/only partially supported in Erlang 22
and will be removed completely in Erlang 24 next year.
Part of rabbitmq/rabbitmq-server#2392
Helps with troubleshooting hostname resolution behavior
on nodes and locally for CLI tools. This is obviously not meant
to be a replacement for existing tools such as dig, only
a way to quickly spot obvious irregularities, e.g. those
in environments that use custom Erlang inetrc files.
Per discussion @harshac.
During the 3.8.4 cycle we have backported `rabbit_env` to v3.8.x.
Instead of messing with env variable prefixing, it tries both
RABBITMQ_{VAR} and {VAR} environment variables. However,
in CLI tools node name currently only picks up RABBITMQ_NODENAME,
so environments where node name has to be explicitly configured
via rabbitmq-env.conf:
NODENAME=rabbit@our.custom.hostname
would not pick this node name up. RABBITMQ_NODENAME had to be added
as a workaround.
With this change the behavior of CLI tools and the server is closer.
Note that this updates a few places which used `Config.get_option/2`
to get a "default node name" which more often than not ended up
being a node prefix ("rabbit"). Those tests had to be updated
to use `Config.default/1`.
Closes#421.
References c8e766dec7, 8a5ab87038.
It prints RabbitMQ-specific environment variables that
are set on the target node. Can be used to inspect env variable-based
configuration without access to the target host.
The readiness is similar to that of 'rabbitmq-diagnostics check_if_node_is_quorum_critical'
but this command awaits for it up to --timeout seconds.
While at it, refactor DefautOutput to detect and support JSON formatting
of most basic return values suc has :ok or {:error, map}.
Part of #408.
The context is either initialized from the CLI's process environment or
from the remote node's own context.
This is required to e.g. find plugins or Mnesia directory.
In `code_path`, we don't append `ebin` anymore to the code path because
the `rabbit` application is now packaged as an .ez archive like plugins.
This simplifies the overall layout of the project.
Some streaming commands with a duration argument can send the empty
string as the output (along with a finishing marker). This case was not
handled properly and would result in a stack trace when the command
returned once the duration has elapsed.
It makes a lot of assumptions about Lager's log flush
timing and can be tripped by the peak rate protection
mechanism. This test module has a high rate of false
positives on Concourse.
There is another test that asserts over a "folded" stream, so
code coverage is kept about the same.
Arnaud Cogoluègnes
Michael Klishin
dcorbacho
Jean-Sébastien Pédron
Loïc Hoguin
Michal Kuratczyk
Michael Klishin
Luke Bakken
Jean-Sébastien Pédron
kjnilsson
Ayanda-D
Anupama Singh
Michael Klishin
Whitespirit0