They were trying to run `hostname` and `which`, which produced a bunch
of error messages in a hermetic build environment.
And performance of those `shell` calls is not very important, as they
are caled just a few times during script runtime anyway (there is a
hack to make these lazy, but evaluating only once - but it's hardly
worth it).
Adds WORKSPACE.bazel, BUILD.bazel & *.bzl files for partial build & test with Bazel. Introduces a build-time dependency on https://github.com/rabbitmq/bazel-erlang
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.
Subsequent nodes fail to start since ports are already in use. This
makes it possible to start multiple nodes locally with all plugins
enabled.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The CLI has a high startup time. To speed up the
`start-background-broker` and `stop-node` recipes, two CLI calls are
replaced by two more basic commands which achieve the same goal.
The documentation says we should be able to use ?=, but apparently it
affects the way variables are passed to sub-make.
The issue we had is that using: `make start-cluster RABBITMQ_CONFIG_FILE=...`
didn't work as expected: `$(RABBITMQ_CONFIG_FILE)` made it to the
sub-make but not to the sub-make's recipe.
Using := fixes the problem.
Doing that is ok because assigning `$(RABBITMQ_CONFIG_FILE)` in the
environment or on make(1)'s command line will override the
target-specific variable anyway.
They were plain by default & are now blue which works really well with
Gruvbox Dark. I couldn't change just the debug color, had to redefine
them all.
cc @dumbbell @lukebakken
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
When running the broker locally, in dev, this is what most of us want.
To change this, use e.g. RABBITMQ_LOG=info (previous default).
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
This turns off WAL preallocation and saves 400+ MiB per node directory.
This setting only applies to nodes started with `make run-broker` or
from our testsuites. RabbitMQ default configuration remains unaffected.
Exactly as we previously set the file log level to debug.
Note that it does not enable logging on the console, it only changes the
default log level if the user of `make run-broker` enables console
logging (using `make run-broker RABBITMQ_LOGS=-`).
[#171131596]
The previous value accepted for this behavior was "NONE". But it's more
intuitive to set it to nothing.
`rabbitmq-run.mk` is also updated to allow `$RABBITMQ_ENABLED_PLUGINS`
to be overriden e.g. on the command line.
This is handled by the `rabbitmq_prelaunch` application now, based on
the value of `$RABBITMQ_ENABLED_PLUGINS`.
`$(RABBITMQ_ENABLED_PLUGINS_FILE)` depended on `dist`. This dependency
was moved to individual `run-*` and `start-*` targets.
While here, re-use `test-dist` instead of `dist` if the build was
already done for tests.
The testsuites default to run `make test-dist` as a first step.
Therefore later, when it starts a node, it should re-use that instead of
depending on `make dist` which will rebuild the tested project and
remove test dependencies from plugins.
This is useful (and mandatory in fact) now that `rabbit` is packaged
like plugins because, in the case of rabbitmq-erlang-client for
instance, the broker is a `$(TEST_DEPS)`: if starting a node runs `make
dist`, the broker will be removed.
... to the plugin being worked on, instead of locating `rabbit` and
taking the scripts there.
It greatly simplifies the use of RabbitMQ and plugins inside a
development working copy because the layout is closer to what we would
have in a package. I.e. there are far less special cases.
... when we wait for a node started in the background.
This helps when the PID is written asynchronously by the Erlang node
instead of the rabbitmq-server(8) script: in this case, the `rabbitmqctl
wait` command may start to wait earlier in the former situation than the
latter one, and thus timeout earlier.
This saves a lot of time because:
1. we don't spawn a shell each time to compute the same value;
2. elixir(1) has a long startup time.
In my tests, a no-op gmake in `rabbit` goes from 2.5 seconds to 0.9
seconds.
... instead of Unix commands and a one-liner which assumes that `:` is
the path separator. This speeds up the build because we don't spawn a
shell.
While here, also remove `$(APPS_DIR)` from `$(ERL_LIBS)`.
We don't need this anymore, now that the high watermark is bumped
automatically when the log level is set to `debug` in rabbit_lager.
This reverts commit 49956c6423.
The stop-node command is the only make target still using erl_call who
is prone to breakage (broken in OTP 21.3) and can readily be replaced
with rabbitmqctl stop.
Alexey Lebedeff
Pavel Heimlich
Arnaud Cogoluègnes
kjnilsson
Philip Kuryloski
Jean-Sébastien Pédron
Gerhard Lazu
dcorbacho
Luke Bakken
Jean-Sébastien Pédron
Luke Bakken