The problem with this approach is that the application is not included in the application list, even though it’s required at runtime. This means you can’t build a proper OTP release with distillery (I’m presuming you’re not doing it now, but might want to do in the future). Any other tool which relies on the application list will also not work properly.

Instead of using runtime: false, you could instead add the vmstats application to the included_applications list:

# mix exs
# ...
def application do
  [
    included_applications: [:vmstats],
    # ...
  ]
end

And then somewhere in the supervision tree include %{id: :vmstats, start: {:vmstats, :start, [:normal, []]}} as a child. This will work properly with distillery, since application will be included in the release, but it won’t be started when the release is booted. Instead, the app is started in your own supervision tree.

Alternatively you could use vmstats normally (i.e. drop included_applications and runtime: false). In your app startup callback you could invoke something like Application.put_env(your_app, :statix_connected?, true) immediately after invoking Statix.connect, and then in your sink callback function push the data only if Application.get_env(your_app, :statix_connected?) == true.

AFAIK the sasl is no longer an issue in OTP 21, since the logs are now produced by the erlang’s new :logger that is always started. sasl is now only what it was always supposed to be - just tooling for releases.

@leifericf I’m running into a similar problem trying to send vmstats information to statsd via statix. I need to ensure that statix has connected to the statsd server before the vmstats application has started. The solution I came up with was to set the vmstats dependency to runtime: false and manually start it in my main application.

  defp deps do
    [
      # ...
      {:vmstats, "~> 2.3.0", runtime: false}
    ]
  end

  def start(_type, _args) do
    :ok = Strategies.Statix.connect()
    Application.start(:vmstats)

    Supervisor.start_link([], strategy: :one_for_one, name: MyApp.Supervisor)
  end

It would be fantastic if there was some way to specify the order in mix.exs without clobbering all applications by adding the applications key to def applications