The post FusionReactor 8.6.0 Released appeared first on FusionReactor Observability & APM.

FROM ortussolutions/commandbox:3.0.2
LABEL maintainer “Example Person”

# Environment Variables
ENV FR_LICENCE “”
ENV FR_GROUP “Local”
ENV CFENGINE “lucee@5.3.6+61”
ENV HEADLESS “true”

COPY . /app
RUN box install commandbox-fusionreactor –verbose

# WARM UP THE SERVER
RUN ${BUILD_DIR}/util/warmup-server.sh

You could of course add the Fusion Reactor module as a dependency in your `box.json` and do `box install` within your Dockerfile too; it’s up to you.

Checking it Worked

If all goes according to plan, when rebuilding your image, you should see some extra log lines:

Additionally, you should see some debug information after the warmup/install process:

Lastly, and most importantly, you should see the server pop up at https://app.fusionreactor.io/

Group all the things!

The `cloudGroup` passed into the Fusion Reactor module config is optional, but highly recommended, especially if like me you have multiple AWS environments for staging/production. As we can set these via environment variables, it makes tracking down a troublesome request a lot easier.

Server online counts

One caveat is to not panic about the number of offline servers that Fusion Reactor displays. In your Fargate cluster, if you have specified a certain number of tasks which must be running – say 4 instances – then each time you do a deployment, the 4 old tasks will be killed and 4 new ones take their place. If you botch a deploy or something like a configuration option doesn’t work, then there’s a risk that Fargate goes into a bit of a loop, constantly shutting down and starting servers to get a healthy one. This can mean your offline server count might spiral as Fusion Reactor UI still displays your unhealthy servers for 7 days or so by default.

The post Getting Started With FusionReactor in CommandBox and Docker appeared first on FusionReactor Observability & APM.

In this video Brad Wood of Ortus Solutions introduces you to FusionReactor Cloud and Docker Swarm

“We’ve made a new screencast that shows an introduction to FusionReactor Cloud, a new way to monitor any number of servers in a consolidated interface that can scale up and down with your infrastructure. Not only do new servers automatically register and deregister themselves with the Cloud dashboard, but it supports a pay-for-what-you-use model that prevents you from locking into a specific number of licenses.

This is a great fit for deployments like Docker Swarm where you can scale your service up and down from day to day. In this demo, I’ll show you how to add FusionReactor cloud easily into any CommandBox-based server and show how to deploy it to a Docker Swarm on our Ortus Docker image and then play around with it.” Brad Wood, Ortus Solutions (Follow him on Twitter)

The post Screencast Intro to FusionReactor Cloud & Docker Swarm Demo – Brad Wood appeared first on FusionReactor Observability & APM.

Firstly, what is Apache Kafka. Apache Kafka is a publish-subscribe service that allows for multiple system to publish to a given topic and for multiple system to create from a topic. It is commonly used to build real time data pipelines because it is reliable, fast and scalable. To find out more about Apache Kafka visit there website: https://kafka.apache.org/

There are two major aspects of using Kafka the consumers and producers. In this post we are going to talk about how FusionReactor can monitor consumer applications.

Consumer Transactions

When you start your application with FusionReactor (see Install Guide) we will automatically detect and start tracking calls to the Kafka brokers. These calls are then tracked into transactions and displayed in the Transaction History page.

These transaction track the topic that is being polled and the partition that was polled, as well as the number of records returned and the consumer group used. From these transactions we also graph the activity and execution time into the normal transaction graphs in FusionReactor.

In addition to the standard graphs in FusionReactor if you are using an Enterprise or Ultimate license you will also have access to the ‘Framework Source’ page this page will aggregate the Kafka metrics into a selection of graphs to show how the Kafka usage breaks down by, Broker, Topic and Partition.

Consumer Metrics

When you have a Java application connected to Kafka, there are various metrics available from the driver library. FusionReactor is able to track these metrics and display them over time in a collection of graphs. FusionReactor provides two pages of these graphs Kafka Metrics and Kafka Node Metrics, each page is then displayed based on the selected consumer.

Kafka Metrics

The Kafka Metrics page is intended to give a general overview of the state of the applications use of Kafka, so on this page you will see metrics including:

• Records consumed
• Incoming/Outgoing Bytes
• Commit Rate
• Heartbeat Rate
• And many more..

Kafka Node Metrics

The Kafka Node Metrics include metrics for each consumer that is running in the JVM, split down to each node that is providing the data. These metrics include:

• Incoming/Outgoing Bytes
• Latency
• Request Size
• And many more..

For more information about what these metrics are please visit the Apache Kafka documentation

The post Monitoring Kafka Consumer Applications appeared first on FusionReactor Observability & APM.

Firstly, what is Apache Kafka. Apache Kafka is a publish-subscribe service that allows for multiple system to publish to a given topic and for multiple system to create from a topic. It is commonly used to build real time data pipelines because it is reliable, fast and scalable. To find out more about Apache Kafka visit there website: https://kafka.apache.org/

There are two major aspects of using Kafka the consumers and producers. In this post we are going to talk about how FusionReactor can monitor consumer applications.

Consumer Transactions

When you start your application with FusionReactor (see Install Guide) we will automatically detect and start tracking calls to the Kafka brokers. These calls are then tracked into transactions and displayed in the Transaction History page.

These transaction track the topic that is being polled and the partition that was polled, as well as the number of records returned and the consumer group used. From these transactions we also graph the activity and execution time into the normal transaction graphs in FusionReactor.

In addition to the standard graphs in FusionReactor if you are using an Enterprise or Ultimate license you will also have access to the ‘Framework Source’ page this page will aggregate the Kafka metrics into a selection of graphs to show how the Kafka usage breaks down by, Broker, Topic and Partition.

Consumer Metrics

When you have a Java application connected to Kafka, there are various metrics available from the driver library. FusionReactor is able to track these metrics and display them over time in a collection of graphs. FusionReactor provides two pages of these graphs Kafka Metrics and Kafka Node Metrics, each page is then displayed based on the selected consumer.

Kafka Metrics

The Kafka Metrics page is intended to give a general overview of the state of the applications use of Kafka, so on this page you will see metrics including:

• Records consumed
• Incoming/Outgoing Bytes
• Commit Rate
• Heartbeat Rate
• And many more..

Kafka Node Metrics

The Kafka Node Metrics include metrics for each consumer that is running in the JVM, split down to each node that is providing the data. These metrics include:

• Incoming/Outgoing Bytes
• Latency
• Request Size
• And many more..

For more information about what these metrics are please visit the Apache Kafka documentation

The post Monitoring Kafka Consumer Applications appeared first on FusionReactor Observability & APM.