The Flare profiler for Minecraft servers

What is Flare?

Flare is a profiling suite for Minecraft dating from the 1.16 era.
Used to be a competitor to spark and timings, where timings got deprecated and stopped receiving updates and Flare got abandoned due to the owner's new schedule and therefore lack of time.

Why bringing it back?

No particular reason.
I learned Nuxt and wanted to put my new skills to the test.
Out of a couple of ideas, Flare looked like the most complex one. And given that there was no public instances available even if the profiler itself has been open source and still remained untouched for years, it looked like a promising idea to bring it back.

Features

Most of the features Flare used to advertise are now (and have been) a thing in spark for years.
Remember we're talking about 1.16, back when spark was not as feature-rich as it is today.

1. Thread profiling
2. Allocation profiling
3. View server configurations
4. Timeline graphs
5. System information

Flare vs spark

There are not many reasons to use Flare nowadays compared to spark, most of its features have already been merged into spark and have been enjoyed by server owners for years.
If I had to mention reasons to use Flare would be the ability to take a cpu and memory profiler on all threads, both at the same time, where in spark you have to choose between one or the other.
And the ability to report garbage collector (GC) pauses and create a graph with them, allowing you to visually see the pause spikes in a graph without having to set up a tool like Unified Metrics.

Getting started

First, identify your server software.
If you're running Pufferfish or any of its forks, flare its already bundled!

In your pufferfish.yml file, look for this section and fill up the details.
You will need to provide a URL to the flare instance (the viewer) you're going to use and an authorization token:

# Configures Flare, the built-in profiler
flare:
  # Sets the server to use for profiles.
  url: "https://flare.airplane.gg"

# Options for connecting to Pufferfish/Airplane's online utilities
web-services:
  token: ""

If you're not using a pufferfish-based software, you can still use the Flare plugin made by @Toffikk.
In your /plugins/Flare/config.yml you'll find the same details, but the URL will be split into backend and frontend.
You only need to provide backend-url with the URL to the flare instance, unless stated by the flare instance you're using.

profiling:
  token: ""
  backend-url: "https://flare.airplane.gg"
  frontend-url: ""

Now, optionally, you can add the following JVM flags to your startup script to improve accuracy when profiling.
These flags are not required for Flare to work, but will allow async-profiler, the tool that makes both spark and Flare possible, to also profile non safepoints, you can read more about the safepoint bias here.

-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints

Once you have provided both a URL and your token, you can start profiling!
In the original Pufferfish and the Flare plugin, you can start profiling by using the command:

/flare start

In unofficial implementations of Pufferfish like Puffernot you will use the command:

/flare profiler start

No public instances available?

You might be asking: Why does it require a token compared to spark?
Flare, at least the viewer, used to be a paid product, which required a token to access.

I, with the help of @Toffikk, have built a viewer from the ground up.
The new flare-viewer is fully open source, but we have kept the token functionality, mostly as a way to keep control over your own instance without having to set up a firewall, for those that want to keep it for themselves.

Still, you're able to deploy your own instance and share it with your friends, or with the whole community!
I do not share mine, because my vps is dogshit
For this you will need two projects:

1. flare-viewer, the web UI for Flare.
2. Jet, the backend for the viewer.

Compared to spark, Jet would be the equivalent to bytebin, and flare-viewer to spark-viewer.

You can compile each project by following the instructions on their respective repositories.
Or you can use the provided docker images, available in the GitHub Container Registry (ghcr). You can find the compose.yml entries I use inside each repository.

As you might notice, there are two projects that, by default, will hold different paths.
This is why the Flare plugin provides a backend and frontend URLs. If you're unable to configure any sort of forwarding, you can just rely on that feature, where backend-url will be the path for Jet, and frontend-url will be the path for flare-viewer.

If you're using docker, have both projects in the same machine, and are using Caddy, you can take my configuration to make yours forward the connection, and only require to provide a single url (which will also make it compatible with the original Pufferfish).

flare.biquaternions.me {

    @jet {
        path /create /license /api/thumbnail/*
    }
    reverse_proxy @jet jet:9420

    @profiling {
        path_regexp flare_keys ^/[A-Za-z0-9_-]+/[A-Za-z0-9_-]+(/timeline)?$
    }
    reverse_proxy @profiling jet:9420

    reverse_proxy flare:3000

}

jet.biquaternions.me {
    reverse_proxy jet:9420
}

jet-live.biquaternions.me {
    reverse_proxy jet:9430
}