[![CI build and push](https://github.com/cryostatio/cryostat/actions/workflows/push-ci.yaml/badge.svg "Continuous Integration")](https://github.com/cryostatio/cryostat/actions/workflows/push-ci.yaml) [![Quay Repository](https://img.shields.io/badge/Container_Image-cryostat/cryostat-teal.svg "Quay Repository")](https://quay.io/repository/cryostat/cryostat) [![Google Group : Cryostat Development](https://img.shields.io/badge/Google_Group-Cryostat_Development-blue.svg "Mailing List")](https://groups.google.com/g/cryostat-development) A container-native JVM application which acts as a bridge to other containerized JVMs and exposes a secure API for manging, storage, retrieving, and analyzing JDK Flight Recorder data, thread dumps, heap dumps, `async-profiler` sessions, and more from your cloud workloads. ## SEE ALSO * [cryostat.io](https://cryostat.io) : upstream documentation website with user guides, tutorials, blog posts, and other user-facing content. Start here if what you've read so far sounds interesting and you want to know more as a **user**, rather than as a _developer_. Here you will find instructions on how to install Cryostat using the [Cryostat Operator](https://github.com/cryostatio/cryostat-operator) or [Cryostat Helm Chart](https://github.com/cryostatio/cryostat-helm), how to configure your applications to enable connectivity, and how to use the Cryostat application. * [cryostat-agent](https://github.com/cryostatio/cryostat-agent): a JVM Agent that implements Cryostat target application discoverability as well as additional capabilities not supported by JMX connections. * [cryostat-core](https://github.com/cryostatio/cryostat-core) : the core library providing a convenience wrapper and headless stubs for use of JFR using JDK Mission Control internals. * [cryostat-operator](https://github.com/cryostatio/cryostat-operator) : an Operator for deploying Cryostat in your OpenShift or Kubernetes cluster. * [cryostat-helm](https://github.com/cryostatio/cryostat-helm) : a Helm Chart for deploying Cryostat in your OpenShift or Kubernetes cluster * [cryostat.wiki](https://github.com/cryostatio/cryostat/wiki) : this repository's wiki page, containing further configuration samples for ex. Docker Compose * [cryostat-web](https://github.com/cryostatio/cryostat-web) : the React frontend included as a submodule in Cryostat and built into Cryostat's OCI images. * [JDK Mission Control](https://github.com/openjdk/jmc) : the desktop application complement to JFR. Some parts of JMC are borrowed and re-used to form the basis of Cryostat. JMC is still a recommended tool for more full-featured analysis of JFR files beyond what Cryostat currently implements. * [binjr](https://github.com/binjr/binjr) : a timeseries visualization desktop application which supports reading JFR files This repository contains the source code for Cryostat versions 3.0 and later. Cryostat (née "container-jfr") versions prior to 3.0 are located at [cryostatio/cryostat-legacy](https://github.com/cryostatio/cryostat-legacy). Container images from both are published to the same [`quay.io`](https://quay.io/repository/cryostat/cryostat) repository. ## CONTRIBUTING We welcome and appreciate any contributions from our community. Please visit our guide on how you can take part in improving Cryostat. [See contribution guide →](./CONTRIBUTING.md) ## REQUIREMENTS Build requirements: - git - JDK 25+ - Maven v3+ - [Quarkus CLI](https://quarkus.io/guides/cli-tooling) v3.33.1+ (Recommended) - [Podman](https://podman.io/docs/installation) 4.7+ Smoketest run requirements: - [`yq`](https://github.com/mikefarah/yq) v4.35.1+ - [docker-compose](https://docs.docker.com/compose/install/) v1.29.2 - [podman-docker](https://packages.fedoraproject.org/pkgs/podman/podman-docker/) (Optional) General run requirements: - an OpenShift or Kubernetes cluster - recommended installation methods: [`cryostat-operator`](https://github.com/cryostatio/cryostat-operator) or [`cryostat-helm`](https://github.com/cryostatio/cryostat-helm) - OR any other container platform which can host OCI containers ## BUILD This project uses Quarkus, the Supersonic Subatomic Java Framework. If you want to learn more about Quarkus, please visit its website: https://quarkus.io/ . ### Setup Dependencies For ease and convenience, it is suggested to use `podman` with the following configurations: ```bash $ systemctl --user enable --now podman.socket $ # hack to work around testcontainers/podman "Broken pipe" issue $ mkdir -p $HOME/.config/containers/containers.conf.d $ echo -e "[engine]\nservice_timeout=0" > $HOME/.config/containers/containers.conf.d/999-service-timeout.conf ``` `$HOME/.bashrc` (or equivalent shell configuration) ```bash export DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock ``` If developing using `docker` then the above should be unnecessary. Initialize submodules before building: ```bash $ git submodule init && git submodule update $ cd src/main/webui $ yarn install && yarn yarn:frzinstall $ cd - ``` ### Build the application container image The application image can be created using: ```bash # With Maven $ ./mvnw package # Or with Quarkus CLI $ quarkus build ``` ### Build and run the application in dev mode You can run your application in dev mode that enables live coding using: ```bash # With Maven $ ./mvnw compile quarkus:dev # Or with Quarkus CLI $ quarkus dev ``` This will run Cryostat as a local JVM process hooked up to its frontend, and required companion services in containers. Any changes made to the backend or frontend sources, `application.properties`, `pom.xml`, etc. will trigger automatic rebuilds and live-coding. > **_NOTE:_** Quarkus now ships with a Dev UI, which is available in dev mode only at http://localhost:8181/q/dev/. ### Run the application with dev mode frontend You can run the server setup with a live coding frontend instance using: `terminal 1` ```bash $ ./smoktest.bash -t ``` `terminal 2` ```bash $ cd /path/to/cryostat-web # this can be ./src/main/webui , or a separate clone of the cryostat-web repository $ yarn yarn:frzinstall $ yarn start:dev ``` This will run Cryostat, required companion services, and test applications in a podman/docker compose container setup. Changes to frontend sources in `/path/to/cryostat-web` will trigger automatic rebuilds and live-coding of the web UI only. This is often useful for frontend development compared to the previous dev mode setup, since it allows for the full suite of test applications to be deployed. The Quarkus Dev UI is not available in this setup. ## RUN ### Docker/Podman Compose `smoketest.bash -n` can be used to generate a compose manifest YAML definition for use with `docker-compose` or `podman-compose`. Check `smoketest.bash -h` for a listing of available options. For example, to generate a compose file (`-n`) that uses `cryostat-reports` for automated analysis report generation (`-r`), with Cryostat 4.1.0 attached to an external S3-compatible object storage instance (`-s ext`), run: ```bash CRYOSTAT_VERSION=4.1.0 \ CRYOSTAT_USER=myuser \ CRYOSTAT_PASS=changeit \ S3_ENDPOINT=https://example.com \ AWS_ACCESS_KEY_ID=abcd \ AWS_SECRET_ACCESS_KEY=1234 \ ./smoketest.bash -n -r -s ext > cryostat-compose.yaml ``` (replace the environment variable values with the authproxy username/password you would like to use and actual values for your object storage provider) You can then use `cryostat-compose.yaml` to set up or tear down your Cryostat instance using ex. `podman compose up -f cryostat-compose.yaml`. The `smoketest.bash` script will take care of generating some local volume tarballs for Cryostat configuration files, and captured data will be stored in your configured object storage instance. By modifying this compose file, or taking pieces from it to add to your other compose manifests, you can add Cryostat in to a compose deployment. To initialize Cryostat's configuration volumes after running the `smoketest.bash -n` script, use the following: ```bash for i in *.tar ; do \ f=$(echo $i | cut -d. -f1); \ echo "Creating volume ${f} from ${i}"; \ podman volume create $f; \ podman volume import $f $f.tar; \ done ``` or check the [Cryostat Wiki](https://github.com/cryostatio/cryostat/wiki/Deploying-Cryostat-in-Docker-or-Podman-Compose) page for pre-generated initialization volumes with simple configuration defaults. ### Local Smoketesting Development on this project is primarily done using `podman`, though things should generally work when using `docker` as well. Ensure you have performed the `podman` setup above first, then build the container image and run smoketests. This will spin up the cryostat container and its required services. ```bash # build Cryostat container, clean up any dangling container images/layers $ ./mvnw package ; podman image prune -f # alternatively, use Quarkus CLI instead of the Maven wrapper $ quarkus build ; podman image prune -f # check the available smoketest options $ bash smoketest.bash -h # run a smoketest scenario $ bash smoketest.bash -O # without the -O flag, the smoketest will pull the latest development image version, rather than the one you just built ``` To make containers' names DNS-resolvable from the host machine, do: ```bash $ git clone https://github.com/figiel/hosts libuserhosts $ cd libuserhosts $ make PREFIX=$HOME/bin all install $ echo 'export LD_PRELOAD=$HOME/bin/lib/libuserhosts.so' >> ~/.bashrc $ export LD_PRELOAD=$HOME/bin/lib/libuserhosts.so ``` (this will require a C compiler toolchain present on your development machine) You can verify that this setup works by running `smoketest.bash`, and then in another terminal: ```bash $ LD_PRELOAD=$HOME/bin/libuserhosts.so ping auth $ LD_PRELOAD=$HOME/bin/libuserhosts.so curl http://auth:8080 $ LD_PRELOAD=$HOME/bin/libuserhosts.so firefox http://auth:8080 ```