Connecting Your Data Sources
A Forwarder is how Java information enters your installation. AMT and the Azul IC Agent do the detecting on your hosts, and the Forwarder is the road their observations travel over your network. Until one runs, your installation holds nothing.
Getting there takes three steps, in this order:
-
An Admin registers a Forwarder under Settings and copies its access key.
-
Someone installs that Forwarder in the network location it serves and starts it.
-
AMT and the Agent send their observations through it.
Registering a Forwarder
An Admin registers a Forwarder under Settings > Data Source Setup. Registering is the only way a Forwarder gains access, and it mints two things:
-
A public identifier, in the form
fwd-…. This is the Forwarder’s identity everywhere it appears: in the connection list, on a JVM record, and in the API. -
A secret access key. This is the only thing you configure on the Forwarder’s host.
Everything else a Forwarder needs, it learns. When it checks in, it receives its write path (which contains its identifier), the storage backend to use, the delivery file limits, and the clock it names its files by. There is nothing in its configuration to keep in step with anything in your installation, which is why moving the inbox or switching storage backends needs no visit to the host. The exception is an S3-compatible bucket with a private certificate, which needs the truststore settings on the Forwarder host. See Storing in an S3-Compatible Bucket.
The Forwarder’s own page carries its full state and every operation on it: reveal or reissue the access key, edit tags, rename it, disable it, enable it, delete it. The access key stays readable there, masked until you reveal it, and the page offers a pre-populated settings file you can copy or download with the real key and the address of your installation already in it. When your installation stores deliveries in an S3-compatible bucket with a private certificate, add the truststore settings for the bucket to that file. See Storing in an S3-Compatible Bucket.
Two rules protect a registration that nobody is using:
-
Deleting a Forwarder revokes its access. The Forwarder stops delivering at its next status poll, within about 10 seconds, and drops the data it receives from then on. Deliveries it wrote before are skipped when your installation next picks deliveries up, because your installation does not necessarily own the permissions on that storage. On the S3 backend, the Forwarder’s current write grant also expires within 15 minutes by default and is not renewed.
-
An access key that goes 365 days without being used, whether it was never used at all or simply has not been used since, is withdrawn. The Forwarder then reads as key expired rather than as something an operator turned off. Reissuing the key is the way back, which is also the right handling of a credential that has sat unused that long.
A connection presenting a key that matches no registration is refused. The refusal goes to your application log, recorded as an unrecognised key and never with the key itself. It is not an audit-log entry, because nobody performed it. See Audit Log.
Tagging a Forwarder
Tags are how you answer which Java one business unit owns, or what runs in a single data center. They are the one piece of your own vocabulary the inventory carries, so they are worth thinking about before you have many Forwarders.
Tags belong to your installation and only to your installation. An Admin sets them on the Forwarder’s page, edited as chips: you type env=prod into one field. The Forwarder is never told them, cannot change them, and carries them in no payload, header, or file name. Nothing on its host changes when its inventory is re-labelled, so editing the chips is the whole re-labelling procedure.
Tags are resolved when the inventory is read, not stamped onto rows when data arrives. That is what makes the correction worth having: re-labelling a Forwarder moves everything it ever reported, including inventory from months ago, with no re-ingestion and no reconfiguration anywhere.
Three rules decide what a record ends up carrying:
-
A record’s tags are the ones its own observations declared, overlaid by the ones its Forwarders carry. The Forwarder wins a collision on the same key, because its tags are what an Admin set on purpose and can change, while a JVM’s are whatever its host happened to be configured with when the process started.
-
Keys and values are compared exactly as written.
Envandenvare two different tags. A tag is the literal text somebody chose, and folding the case would group your inventory under a key you cannot see. -
A key may be up to 255 characters and a value up to 1024. A longer one is refused, naming the offender, at registration and at every later change.
The Data Source Setup list shows a Forwarder’s own tags unmerged, because the two views answer different questions: the inventory answers how a JVM is labelled, and this list answers what a sender is labelled.
Tags Are Not Identity
A Forwarder’s identity is its fwd-… identifier. Two Forwarders carrying identical tags are two Forwarders with two identifiers, distinguishable everywhere they appear, and re-tagging one never splits or merges its history.
The access key alone decides whether a connection is recognised.
On-Premises Forwarder
The Forwarder runs entirely inside your network. In on-premises mode it answers the Agents' handshake itself, with no connection to any Azul service, terminates the traffic from your JVMs, and delivers it as sealed files to your installation’s inbox. The Forwarder doesn’t check credentials of Agents or AMT, so allow connections to its port only from your hosts.
Its only conversation with your installation is a check-in when it starts and a periodic status poll after that, each carrying just its access key. The poll is where a disabled Forwarder finds out, so it stops delivering rather than writing files nobody will read.
An unreachable installation doesn’t stop delivery, because the data doesn’t go through it. With filesystem storage, nothing is lost. With S3 storage, uploads stop once the current upload grant expires; completed files then wait in memory, and after a long outage the oldest are dropped. See When the Forwarder Cannot Deliver.
For how to download, configure, and start it, see Installing the Forwarder.
What Sends Data
Once a Forwarder runs, both sources send their observations through it. One Forwarder accepts both over the same connection and the same access key, so you deploy one per network location, not one per source type. Neither source has a registration path or a key type of its own.
| Source | What it reports |
|---|---|
Azul IC Agent |
Dynamic detection. Each JVM as it starts and runs, which is what tells you the Java your organization actually uses, and which applications it carries. |
Azul Migration Toolkit (AMT) |
Static detection. Every Java installation a host scan finds on disk, including one that nobody has started in years. |
Both sources feed the same record, so repeated observations of one real installation fold into one entry instead of appearing as separate ones. Each delivery is attributed by the identifier of the directory it was written to, which is a fact about where the file sits rather than about anything inside it. Attribution therefore cannot be lost to a parse failure.
Which installation two observations describe is a question about the machine, not the route, so it is answered from what the collectors report about the host they stand on. See What Makes One Record.
Checking That Data Arrives
Settings > Data Source Setup lists every Forwarder with:
-
Its name and its
fwd-…identifier -
Its status, and its tags
-
The version it last reported. A Forwarder that has reported none says so, rather than showing a blank that reads as an empty string.
-
How many distinct JVMs it has delivered
-
When its first and last deliveries arrived
Use that list to confirm data is flowing before you rely on the inventory.
The list flags a Forwarder as possibly outdated when the version it reports has been running for 90 days or longer since your installation first saw it. That is a local signal that works on an isolated network, because your installation compares the reported version only against its own record of when it first saw it. The version string is whatever the Forwarder calls itself, stored and shown exactly as it arrived.
For the health of the deployment itself rather than of one sender, see Monitoring and Health. The metrics there answer whether data is still flowing at all, and whether the inbox is filling faster than ingestion drains it.