Refresh the Studio screenshots after the Monitoring and instance rebuilds

content/blog/eventum-2-7-0.mdx

@@ -14,17 +14,17 @@ Eventum 2.7.0 is out. Studio carries most of the release: one design system acro
 The [project page](/docs/studio/projects) is now a docked workspace — the files, the configuration and the debug console in one layout, with a single Save covering the configuration and every edited file at once. Debug results survive moving between stages, and a `generator.yml` that fails to parse opens in recovery mode instead of shutting the project.
 
 <ThemedImage
-  lightSrc="/images/studio_ui/project_workspace_light.png"
-  darkSrc="/images/studio_ui/project_workspace_dark.png"
+  lightSrc="/images/blog/eventum-2-7-0/project_workspace_light.png"
+  darkSrc="/images/blog/eventum-2-7-0/project_workspace_dark.png"
   alt="The project workspace in Eventum Studio"
   className="rounded-lg border mt-2"
 />
 
 [Monitoring](/docs/studio/monitoring) and the [instance page](/docs/studio/instances#instance-page) report a running pipeline live: stage throughput, failures over a rolling window, each instance's share of the output load, and host resources. The lists carry the same figures as sortable columns, and their filters live in the page address, so a filtered view can be bookmarked or sent on.
 
 <ThemedImage
-  lightSrc="/images/studio_ui/monitoring_light.png"
-  darkSrc="/images/studio_ui/monitoring_dark.png"
+  lightSrc="/images/blog/eventum-2-7-0/monitoring_light.png"
+  darkSrc="/images/blog/eventum-2-7-0/monitoring_dark.png"
   alt="The Monitoring dashboard in Eventum Studio"
   className="rounded-lg border mt-2"
 />

content/docs/studio/instances.mdx

@@ -95,9 +95,19 @@ An instance opens onto a page of its own, with the lifecycle controls in the hea
   alt="The Overview tab of an instance"
 />
 
-While the instance runs, the **Throughput** chart plots input against output over a moving window, and below it the same per-plugin pipeline the metrics dialog shows, updating while the page is open. A stopped instance leaves the section empty.
+The page opens on what the instance is doing right now. The panel across the top carries the rate events enter and leave the pipeline at, how many of them have failed and how many were dropped, and the totals those rates come from, over three groups of figures:
 
-The **About** card states the project, the emission mode, whether the instance starts with the application, its timezone and its last run. The **Scenarios** card changes which [scenarios](/docs/studio/scenarios) it belongs to.
+| Group | Contents |
+|-------|----------|
+| **Processor** | Share of one core over the last interval, the processor time the instance has used, how long 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 |
+
+**Wait** is time rather than a rate: it accumulates over the run, and a figure growing faster than the processor time means the host is running more instances than it has processors for.
+
+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](/docs/studio/scenarios) it belongs to, which are added and removed there.
 
 ### Settings
 

content/docs/studio/monitoring.mdx

@@ -1,65 +1,71 @@
 ---
 title: Monitoring
-description: The application dashboard — aggregate pipeline flow, throughput and failure charts, each instance's share of the load, and host and process resources.
+description: The application dashboard — every running instance in one line of state, throughput and failures over a moving window, host and process resources, and what each instance occupies.
 ---
 
-Monitoring is the dashboard for the whole application: every running instance added up. It polls every five seconds, and the charts hold the last thirty readings, so each of them covers roughly the last two and a half minutes. With nothing running, the live sections are replaced by a note pointing at [Instances](/docs/studio/instances).
+Monitoring is the dashboard for the whole application: every running instance added up, and each of them apart. It polls every five seconds and holds a moving window of **2.5**, **10** or **30 minutes**, chosen in the page header. With nothing running, the sections that depend on generation are replaced by a note pointing at [Instances](/docs/studio/instances), while the host and process resources stay live.
 
 <Screenshot
   lightSrc="/images/studio_ui/monitoring_light.png"
   darkSrc="/images/studio_ui/monitoring_dark.png"
   alt="The Monitoring dashboard in Eventum Studio"
 />
 
-## Pipeline
+## The line of state
 
-The three stages of generation as one row of totals, each carrying the losses that explain the gap to the next.
+The row under the title is the application in one line: the instances running, the rate each stage of generation is moving events at, the rate at which events are failing, and how full the fullest queue of any instance is. The totals since those instances started close the row — timestamps generated, events produced, events written and events dropped.
 
-| Stage | Total | Losses |
-|-------|-------|--------|
-| **Input** | Timestamps enqueued | — |
-| **Event** | Events produced | Dropped intentionally, and failed to render |
-| **Output** | Events written | Rejected by a destination, and rejected by a formatter |
+| Reading | Meaning |
+|---------|---------|
+| **Input** | Timestamps entering the pipeline per second |
+| **Event** | Events produced from them per second |
+| **Output** | Events written to their destinations per second |
+| **Failing** | Events lost per second, at the event stage and the output stage together |
+| **Fullest queue** | The most loaded queue of any running instance, as a share of what it may hold |
 
-Read left to right, the row locates where events are going missing without opening a single instance.
+Read left to right, the rates locate where events are going missing without opening a single instance: an event rate under the input rate is the event stage dropping or failing to render, and an output rate under the event rate is a destination refusing them.
 
 ## Throughput and failures
 
 The **Throughput** chart plots input against output as rates measured between polls — the rate now, rather than the average since a generator started that the [Instances](/docs/studio/instances) table reports.
 
-The **Failures** chart covers the same window, split into the event stage and the output stage. It is present only while something is failing.
+The **Failures** chart covers the same window beside it, split into the event stage and the output stage.
 
-## Instance load
+## Resources
+
+CPU and memory for the host, disk and network for the Eventum process, each with its history over the window. The memory reading also names how much of the host's memory the Eventum process itself holds.
+
+Read next to the throughput chart, these separate a slow generator from a saturated machine: output that plateaus against a CPU ceiling is a different problem from output that plateaus with the machine idle.
+
+## Instances
 
 <Screenshot
   lightSrc="/images/studio_ui/monitoring_resources_light.png"
   darkSrc="/images/studio_ui/monitoring_resources_dark.png"
-  alt="Instance load and resource usage on the Monitoring dashboard"
+  alt="Instance load and per-instance resources on the Monitoring dashboard"
 />
 
-Each instance's share of the total output rate, stacked over the same window. An instance that dominates the pipeline, or has quietly stopped contributing to it, shows up here.
+Everything about the running instances is one section: a chart of the load over the window, and the table of figures behind it.
+
+**By instance** stacks the output rate of each instance, with the smallest of them folded into a single band, so an instance that dominates the pipeline — or has quietly stopped contributing to it — is visible in the shape of the chart. **By stage** stacks the same window by pipeline stage instead.
 
-## Instance resources
+The search and the quick filters — **Failing**, **At the limit**, **Idle** — narrow the chart and the table together, and colour follows a row from one to the other. Selecting a row opens what that instance is doing beside it: the totals behind its rates, what each of its plugins moved, and the state of both its queues, one link away from [its own page](/docs/studio/instances#instance-page).
 
-What each running instance costs the host, heaviest first — the other half of the load question.
+The table ranks the instances by what they occupy, and sorts by every figure it shows.
 
 | Column | Contents |
 |--------|----------|
 | **CPU** | Share of one processor core over the last poll |
 | **Wait** | Share of that time spent ready to run while waiting for a processor |
-| **Threads** | Threads the instance runs |
+| **Output** | Events written per second |
+| **Failures** | Events lost per second |
 | **Disk write** | Bytes per second written through the file system |
 | **Network out** | Bytes per second sent |
 | **Events queue** | Memory the batches waiting between the event and the output stage occupy, against the limit they may |
+| **Threads** | Threads the instance runs |
 
 **Wait** is what separates an instance the machine cannot keep up with from a slow one: a figure that climbs across every instance means more of them are running than the host has processors to run, while a single hot instance next to calm ones names the generator to stop.
 
 <Callout type="info">
 Outside Linux the operating system does not account for waiting or file system bytes per thread, so **Wait** and **Disk write** read as zero there. The rest are reported on every platform.
 </Callout>
-
-## Resources
-
-CPU and memory for the host, disk and network for the Eventum process, each with its recent history. The memory reading also names how much of the host's memory the Eventum process itself holds.
-
-Read next to the throughput chart, these separate a slow generator from a saturated machine: output that plateaus against a CPU ceiling is a different problem from output that plateaus with the machine idle.

content/docs/studio/overview.mdx

@@ -1,6 +1,6 @@
 ---
 title: Home
-description: The Studio home screen — recently modified projects, the state of every registered instance, and quick access to the rest of Studio and the Eventum Hub.
+description: The Studio home screen — recently modified projects, the state of every registered instance, and quick access to the rest of Studio.
 ---
 
 Home is the screen Studio opens on. It answers two questions at once: what you were last working on, and whether anything is currently wrong.
@@ -11,8 +11,10 @@ Home is the screen Studio opens on. It answers two questions at once: what you w
   alt="The Home screen of Eventum Studio"
 />
 
-The **Recent projects** list holds the eight generator projects whose files changed most recently. The **New project** button creates one, and the **Browse Hub** link opens the [Eventum Hub](/hub), the catalog of ready-made generators.
+The **Recent projects** list holds the eight generator projects whose files changed most recently, and the **New project** button creates one.
 
 The rail on the right counts every registered instance by state and lists the five most recently started with their uptime. A failure is visible here without going looking for it, and the **Monitoring** link leads to the [dashboard](/docs/studio/monitoring) behind the counts.
 
+The **Explore** row below leads to the four sections generators are built and run in — [Projects](/docs/studio/projects), [Instances](/docs/studio/instances), [Scenarios](/docs/studio/scenarios) and [Repositories](/docs/studio/repositories), the last of which installs a ready-made generator into the workspace.
+
 The footer states the Eventum, Python and platform versions — the first thing worth quoting in a bug report.

content/docs/studio/settings.mdx

@@ -20,7 +20,7 @@ The Settings page edits the application configuration — the same parameters [e
 | **Server** | How the instance is reached — API, web interface, TLS, authentication, MCP |
 | **Generation** | The defaults every generator inherits |
 | **Paths** | Where generators, logs, the startup file and the keyring live |
-| **Logging** | Level, format, rotation |
+| **Logging** | Level, the level of third-party libraries, format, rotation |
 
 A section holding unsaved edits is marked in the rail, so changes spread across several of them stay visible from wherever you are.
 
@@ -30,7 +30,7 @@ A section holding unsaved edits is marked in the rail, so changes spread across
   alt="The Generation section of the Settings page in Eventum Studio"
 />
 
-Batch size and queue depths decide how much memory generation holds at once. The Generation section works that figure out for you: give it an assumed event size and it reports what full queues will occupy for one generator.
+Batch size and queue depths decide how much memory generation holds at once. The Generation section works that figure out for you: give it an assumed event size and it reports what full queues will occupy for one generator. **Limit memory of events queue** bounds that memory directly: **Maximum event bytes** caps what the events queue holds whatever the batches in it weigh, so a configuration whose events turn out larger than assumed stays within the figure.
 
 The **Save** button appears in the page header once anything is edited and asks for confirmation first. These parameters are read when the application starts, so applying them triggers the same [restart](#danger-zone) the Management page offers, and the interface is briefly unavailable.
 
@@ -70,7 +70,16 @@ The cards at the top identify the instance and the machine under it, and link th
 
 The **Application** card also reports whether the GIL is enabled. Generators run on threads, so the [free-threaded build](/docs/core/introduction/requirements#python) is what lets them run in parallel, and on that build the GIL is normally disabled. It can be enabled back after the application starts — by the `PYTHON_GIL=1` environment variable, by the `-X gil=1` interpreter option, or by an extension module without free-threading support that a plugin imports. Generators keep running, but no longer in parallel, so the row reports that state as a warning. On a standard build the GIL is always enabled and the row is neutral.
 
-The **Instance logs** panel holds the application-wide log: configuration loading, which generators were started, and which of them refused to. A single generator's own log is on its [instance page](/docs/studio/instances#logs).
+The **Instance logs** panel holds the log of the application itself, split into the channels it writes:
+
+| Channel | Contents |
+|---------|----------|
+| **Main** | The application core — configuration loading, which generators were started, and which of them refused to |
+| **Server** | The API and the HTTP server |
+| **Access** | The requests the server served |
+| **MCP** | The [MCP server](/docs/mcp), when it is mounted |
+
+A single generator's own log is on its [instance page](/docs/studio/instances#logs).
 
 ### Danger zone