Instances
The instance list with live throughput and error counts, lifecycle controls, the per-instance metrics diagram, and the instance page with its settings and logs.
An instance is a registered copy of a project with its own identifier, its own runtime parameters and its own log. A project describes how events are generated; an instance is one running of it. Instances are held in startup.yml, so they survive a restart of the application.
Instance list
| Column | Contents |
|---|---|
| Instance | The identifier, unique across the application |
| Project | The project it runs, with a link into its workspace |
| Status | See below |
| Flow | Events per second written, averaged over the time since the instance started |
| CPU | Share of one processor core, averaged over that same time |
| Errors | Failures since that start — red once above zero |
| Written | Events delivered since that start |
| Last start time | When the instance was last started |
The last five columns are runtime figures and exist only while an instance runs. For the rest they are empty and sort last. Intentional drops are not failures and are not counted as errors.
The Flow and CPU columns are averages over the whole run, so a generator that produced a burst and went quiet keeps reporting both. For the figures right now, use the Monitoring dashboard, which measures over a moving window.
Statuses
| Status | Meaning |
|---|---|
| Active | Running and generating |
| Idle | Registered, and not run yet |
| Finished | Ran to completion — the input stage exhausted its timestamps and the generator stopped on its own |
| Failed | Stopped because of an error; the reason is in the instance log |
The Starting and Stopping statuses appear while a lifecycle action is in flight.
Filtering and selection
Search by instance or by project and separate what is running from what is not. The filters are held in the page address, so a filtered list can be bookmarked or passed on.
Selecting rows enables the Start, Stop and Delete actions over the whole selection, so a simulation of a dozen generators comes up in one action. Stopping drains an instance rather than cutting it off.
The Create new button registers an instance: an identifier, the project it runs, and the parameters that project expects.
Per-instance actions
| Action | Available |
|---|---|
| Edit | Always — opens the instance page |
| Rename | While stopped |
| Clone | Always — copies the parameters onto a new instance of the same project |
| Show metrics | While running |
| Show logs | Always |
| Start / Stop | According to the current state |
| Delete | While stopped |
Cloning is the shortest way to run one project at two rates, or against two sets of parameters, at the same time.
Instance metrics
Totals for the instance sit above a diagram of its pipeline, laid out from the input plugins through the event plugin to the outputs. Each node carries its own counters, including what it lost: events dropped or failed while being produced, and events a destination refused or a formatter rejected.
The breakdown names the stage that is losing events instead of leaving it to be inferred from a total. In the dialog above the output writes everything it is handed and the event plugin fails on a fraction of its renders, so the whole gap between what the input enqueued and what was written belongs to the event stage.
Instance page
An instance opens onto a page of its own, with the lifecycle controls in the header and three tabs below.
Overview
The panel across the top leads with the rate events enter and leave the pipeline at, how many have failed and how many were dropped, and the totals those rates come from. Under it, what the run costs, in three groups:
| Group | Contents |
|---|---|
| Processor | Share of one core over the last interval, the processor time used, the time its threads spent waiting for a processor, and how many of them there are |
| Memory in queues | How full the timestamps and the events queue are, in batches and — for the events queue — in bytes against the limit they may occupy |
| Input and output | Bytes read and written through the file system, and bytes sent and received over the network |
Below, the Throughput chart plots input against output over a moving window, and the Pipeline graph shows the same per-plugin counters the metrics dialog holds, updating while the page is open. A stopped instance leaves both empty.
The panel beside them states what the instance is — the project, the emission mode, whether it starts with the application, its timezone and its last run — and the scenarios it belongs to, which are added and removed there.
Settings
The configuration of this instance, over the fields startup.yml holds.
The Runtime section decides how events are emitted — live, at the moments the timestamps name, or sample, as fast as the pipeline allows — whether past timestamps are skipped, whether the instance starts with the application, and the Parameters a configuration reads through ${params.name}. One project serves several instances this way, differing only in a hostname or an output path.
The Generation section overrides the application-wide defaults for this instance alone: batching, queue depths, ordering, write concurrency.
These values are read when a generator starts, so saving a running instance offers to restart it.
Logs
The log this instance writes, as it is written to disk. A Failed instance explains itself here, and a rendering failure names the offending event and the line of the template that raised on it.
Projects
The project list and the generator workspace — file explorer, code editor, plugin inspector, and a console that previews each stage of the pipeline.
Scenarios
Named groups of generator instances with coordinated lifecycle control, a diagram of the global state they exchange, and a live view of that state.