Metrics Reference

This page provides a comprehensive reference of all metrics exposed by Gluesync through the /metrics Prometheus scrape endpoint. Use these metrics to build dashboards, configure alerts, and diagnose performance issues in your Gluesync deployment.

See Prometheus Integration for setup instructions and Grafana Dashboards for a hands-on guide to building dashboards with these metrics.

Metric availability and exposition types

The endpoint combines four sources:

  • Gluesync replication, host, threshold, checkpoint, and connection metrics

  • Standard JVM metrics

  • Ktor HTTP server metrics

  • HikariCP pool metrics when pools have registered with the meter registry

A typical 2.2.11 scrape always includes per-entity gluesync_last_*, gluesync_sma_*, and gluesync_total_* series; host CPU/RAM/network counters; JVM and Ktor HTTP families; the gluesync_threshold_* configuration gauges that have a value (including the entity-heartbeat watchdog); and gluesync_db_connections_active_total for every purpose, even when the count is 0.

These families appear only when the matching subsystem is active:

  • gluesync_read_checkpoint_* — a supported Core Hub-managed CDC reader has persisted a position

  • gluesync_entity_dry_seconds — the stall/freshness monitor has evaluated the entity

  • gluesync_entity_lag_* — the per-entity lag probe has sampled the entity at least once

  • gluesync_source_* and gluesync_cache_* — that entity’s connector can produce the figure, and the last sample is recent enough to publish

  • gluesync_db_connections_active — at least one connection is borrowed (the _total series still emit zeros)

  • hikaricp_* — a HikariCP pool has registered with the meter registry

  • gluesync_threshold_latency_minutes and gluesync_threshold_row_count_drift_percentage — those optional settings are configured

Absence therefore does not always mean that scraping failed. Check up{job="gluesync"} first, then verify that the corresponding feature is active.

In 2.2.11, the Prometheus # TYPE metadata declares the Gluesync last, sma, and host metric families as counter, including values such as CPU load and RAM that can decrease. Their operational behavior is snapshot/gauge-like. Plot those values directly and do not apply rate() to them.

This page’s Exposition type column reports the wire type exactly as emitted. Interpretation notes explain how to query each family safely.

Replication performance metrics

These metrics are emitted per pipeline entity and provide granular visibility into data replication performance. All time values are in milliseconds unless otherwise noted.

Replication metrics normally include these labels:

Label Description

pipelineId

Unique identifier of the pipeline

pipelineName

Human-readable name of the pipeline

entityId

Unique identifier of the replicated entity (table / collection)

entityName

Human-readable name of the entity

sourceAgentId

Agent handling the source read

sourceAgentName

Display name of the source agent: its nickname, or the connector’s commercial name when no nickname is set

targetAgentId

Agent handling the target write

targetAgentName

Display name of the target agent
Label sets vary by metric. Use the Prometheus expression browser or inspect the /metrics output before writing a label join. Every family that identifies a pipeline, an entity, or an agent carries the name beside the id, so filtering by name works across families, checkpoints included.

The name labels arrive in 2.2.11.5. Two consequences for existing queries and dashboards:

  • Adding labels changes the identity of a series. After the upgrade the pre-upgrade series stay queryable for the Prometheus lookback window and then disappear, so a recording rule, an alert, or a panel that joins on labels can behave differently across that window.

  • A name falls back to an id when Core Hub cannot resolve it. An agent is named by its own running service, so an agent that is unassigned, stopped, or failing to load reports its id under sourceAgentName, targetAgentName, or agentName. A pipeline or entity the registry no longer knows reports unknown_pipeline or unknown_entity.

Display by name, join on ids.

Last-batch metrics

Instantaneous measurements from the most recently processed transaction message.

Metric Name Exposition type Description

gluesync_last_transaction_info

Counter

Always 1; the lastTransactionId label carries the last transaction Core Hub confirmed for an entity/target pair. - means that no transaction ID is available. Because each label value creates a series, select the newest series when building a table.

gluesync_last_rows_count

Counter

Rows in the most recently processed transaction message

gluesync_last_read_time

Counter

Source read time for the most recent transaction message (ms)

gluesync_last_write_time

Counter

Target write time for the most recent transaction message (ms)

gluesync_last_storage_time

Counter

Internal storage time for the most recent transaction message (ms)

gluesync_last_end_to_end_time

Counter

Most recent Core Hub internal execution time (ms), measured after the change enters the cache. This is not source-to-target freshness.

Simple moving average (SMA) metrics

Smoothed instantaneous values computed across recent transaction messages. Despite their counter exposition type, plot them directly and do not apply rate().

Metric Name Exposition type Description

gluesync_sma_count

Counter

Moving average rows per transaction message

gluesync_sma_size_bytes

Counter

Moving average payload per transaction message (bytes)

gluesync_sma_read_time

Counter

Moving average of source read time (ms)

gluesync_sma_write_time

Counter

Moving average of target write time (ms)

gluesync_sma_storage_time

Counter

Moving average of internal storage time (ms)

gluesync_sma_end_to_end_time

Counter

Moving average of Core Hub internal execution time (ms)

Cumulative totals

Metric Name Type Description

gluesync_total_count

Counter

Total rows replicated from source to target since process start

gluesync_total_size_bytes

Counter

Total bytes replicated since process start

gluesync_total_snapshot_count

Counter

Total rows replicated during initial snapshot phases

Use rate() for per-second throughput and multiply by 60 for a per-minute row rate:

sum(rate(gluesync_total_count{pipelineName=~"$pipelineName",entityName=~"$entityName"}[$__rate_interval]))

Pipeline health and freshness

Data Freshness

This family is conditional. It is omitted from the scrape until the stall monitor has evaluated the entity.

Metric Name Type Description

gluesync_entity_dry_seconds

Gauge

Seconds elapsed since the entity last received a batch with rows > 0. A value of -1 means no live data has been seen since the process started. Labels include pipelineId, pipelineName, entityId, and entityName.
gluesync_entity_dry_seconds is the primary KPI for detecting stalled or idle pipelines. A pipeline that is dry for longer than its configured dataFlowStall.stallDurationMinutes is a candidate for an alert.

A sawtooth pattern is expected for intermittently active entities: the value rises while idle and resets when data arrives. A continuously rising value means delivery has stopped. Exclude -1 when looking for the longest current stall:

max(gluesync_entity_dry_seconds{pipelineName=~"$pipelineName",entityName=~"$entityName"} >= 0)
Example PromQL — alert when any entity exceeds its own stall threshold
gluesync_entity_dry_seconds
  > on() group_left()
  (gluesync_threshold_data_flow_stall_duration_minutes * 60)

CDC read checkpoints

Checkpoint metrics report the source reader’s persisted CDC position. They are omitted until a supported Core Hub-managed CDC reader has persisted a position.

Since 2.2.11.5 they carry pipelineName and sourceAgentName beside pipelineId and sourceAgentId, plus entityId and entityName. The entity pair is filled in only for the checkpoints Core Hub derives per entity, whose checkpointKey already is an entity id, and is empty for a connector’s own key, which covers a journal or a binlog that several entities share. Both labels are emitted either way: an empty value is how Prometheus spells "not applicable", and a label present on only half a family cannot be selected on.

Metric Name Type Description

gluesync_read_checkpoint_age_seconds

Gauge

Seconds between now and the source timestamp at the persisted read position. Labels include pipelineId, pipelineName, sourceAgentId, sourceAgentName, entityId, entityName, checkpointKey, and kind. This is the primary source freshness/reader-lag KPI.

gluesync_read_checkpoint_position

Gauge

A numeric component of the connector-specific read position. The field label identifies the component.

gluesync_read_checkpoint_position_timestamp_seconds

Gauge

Unix timestamp in seconds represented by the persisted read position.

gluesync_read_checkpoint_info

Gauge

Always 1; labels carry non-numeric checkpoint details such as an Oracle rsId, binlog file name, or AS/400 journal library, name, and receiver.

The checkpoint kind identifies the connector family. Current examples include LogminerCheckpoint, BinlogCheckpoint, As400JournalCheckpoint, and InformixCdcCheckpoint. Numeric position fields vary accordingly:

  • Oracle LogMiner: scnNumber, ssn, and resetlogsId

  • MySQL and MariaDB: binlogPosition and operationSeq

  • AS/400: sequenceNumber

  • Informix: id

Position values are only comparable with the same reader and field over time. Connector position scales differ, so do not compare an Oracle SCN with an AS/400 journal sequence. A flat checkpoint position or zero advance rate, together with a rising age, indicates a stalled reader.

Example PromQL — worst selected source-reader lag
max(gluesync_read_checkpoint_age_seconds{pipelineName=~"$pipelineName",sourceAgentName=~"$sourceAgentName"})
Example PromQL — five-minute checkpoint advance rate per minute
clamp_min(
  deriv(gluesync_read_checkpoint_position{pipelineName=~"$pipelineName",sourceAgentName=~"$sourceAgentName",field=~"$checkpointField"}[5m]) * 60,
  0
)
Checkpoint age is source CDC freshness. gluesync_sma_end_to_end_time and gluesync_last_end_to_end_time measure Core Hub internal execution after a change has entered the cache; they are not substitutes for checkpoint age.

Per-entity CDC lag

These families answer how far behind an entity is, which the checkpoint families above cannot: they report the position of a reader, not the size or the age of what is waiting for it. Lag is measured at the two hops where a change can pile up:

  • gluesync_source_* covers source database to Gluesync: what the source has generated and Core Hub has not read yet.

  • gluesync_cache_* covers local CDC cache to target: what Core Hub has read and not yet written.

The hops are reported separately because they have different causes and different fixes. A reader two minutes behind the source while the cache hop shows twenty hours means the target is the bottleneck, not the source.

The figures come from a probe driven off the CDC poll loop, by default every 15 seconds per entity. GS_ENTITY_LAG_PROBE_INTERVAL_SECONDS sets the interval and disables the probe when set to 0, GS_ENTITY_LAG_PROBE_TIMEOUT_SECONDS bounds a single probe, and GS_ENTITY_LAG_PROBE_CONCURRENCY bounds how many run at once. The probe borrows its connection under the monitoring purpose, which the pool refuses rather than queues, so a measurement is skipped instead of competing with the replication it describes.

All families in this section carry pipelineId, pipelineName, entityId, entityName, sourceAgentId, and, since 2.2.11.5, sourceAgentName.

There is no targetAgentId label, unlike gluesync_last_* and gluesync_total_*. Both backlogs are properties of the source read and of the shared cache, so an entity fanned out to three targets has one figure per hop, not three. Do not sum these series across targets.

Source hop

Metric Name Type Description

gluesync_source_lag_milliseconds

Gauge

How long the oldest change the source has generated and Gluesync has not read yet has been waiting. 0 means the reader is level with the source. A negative value means the source’s clock and the Core Hub host’s clock disagree.

gluesync_source_pending_rows

Gauge

Change rows the source has generated and Gluesync has not read yet. Absent when the connector cannot count them without reading them.

gluesync_source_pending_rows_is_lower_bound

Gauge

1 when the count can only undercount because a hop upstream of the counted one is invisible, 0 when nothing upstream is hidden.

gluesync_source_pending_rows_is_upper_bound

Gauge

1 when the count covers more than this entity alone, such as every entry of a shared AS/400 journal, 0 when it is exact.

gluesync_source_empty_backlog_is_unproven

Gauge

1 when a pending-row count of 0 does not prove the entity is caught up, because the store being counted is filled by something whose position nothing here can read: MSSQL CDC’s capture job, DB2 LUW CDC’s stored procedure. A stopped filler leaves the store empty. In that state gluesync_source_lag_milliseconds is deliberately absent rather than 0.

gluesync_source_log_distance_bytes

Gauge

Bytes between the reader’s position and the head of the source’s change log, such as a WAL or a binlog. This is the distance the reader still has to travel, not this entity’s backlog: the log is shared by the whole database and most of those bytes are changes this entity does not sync. A distance of 0 is a log position, not proof that nothing is waiting.

gluesync_source_oldest_pending_timestamp_seconds

Gauge

Unix timestamp of the oldest change the source is still holding, which is the next one Gluesync will read.

gluesync_source_read_timestamp_seconds

Gauge

Unix timestamp of the last change Gluesync has read from the source.

Cache hop

Only cache-based connectors have this hop. A connector that reads the source and emits directly publishes nothing here.

Metric Name Type Description

gluesync_cache_lag_milliseconds

Gauge

How long the oldest change sitting in the local CDC cache and not yet delivered to the target has been waiting. 0 means the cache is drained. Rising here while the source hop stays flat points at the target write path rather than at the reader.

gluesync_cache_pending_rows

Gauge

Change rows read into the local CDC cache and not yet delivered to the target.

gluesync_cache_pending_rows_is_lower_bound

Gauge

1 when the count can only undercount, 0 when nothing upstream of the cache is hidden.

gluesync_cache_pending_rows_is_upper_bound

Gauge

1 when the count is an upper bound rather than an exact count, 0 when it is exact.

gluesync_cache_empty_backlog_is_unproven

Gauge

1 when a pending-row count of 0 does not prove the cache is drained. Always 0 in 2.2.11: the cache is written by Gluesync itself, so nothing upstream of the count is invisible.

gluesync_cache_pending_bytes

Gauge

Bytes sitting in the local CDC cache between this entity’s read position and the head. Unlike the source log distance, these bytes belong to this entity alone.

gluesync_cache_oldest_pending_timestamp_seconds

Gauge

Unix timestamp of the oldest change in the cache not yet delivered to the target, which is the next one the target will receive.

gluesync_cache_read_timestamp_seconds

Gauge

Unix timestamp of the last change this entity consumed from the local CDC cache.

Probe state

Metric Name Type Description

gluesync_entity_lag_probe_info

Gauge

Outcome of the last probe. One series per possible outcome, carried in the result label, with 1 on the current one and 0 on the others.

gluesync_entity_lag_probe_duration_milliseconds

Gauge

How long the last probe took, so the cost of measuring on the source database stays visible. A rising duration is a source getting slower, not the pipeline being starved.

gluesync_entity_lag_sample_age_seconds

Gauge

Seconds since this entity’s figures were measured. Grows past the probe interval when probes stop completing.

Every outcome is emitted on every scrape rather than only the current one, so a sum by (result) cannot count one entity twice and a recovered entity does not keep reading as failing:

result Meaning

ok

The probe answered. Individual figures can still be absent when the connector cannot produce them.

unsupported

That connector has no probe for this figure. Not a fault.

no_read_position

Nothing has been read for this entity yet, so there is no position to measure a backlog from. Expected on a freshly configured entity, where it clears on the first read, and a fault if it persists.

error

The probe threw. The Core Hub log carries the source error.

timeout

The probe did not answer within GS_ENTITY_LAG_PROBE_TIMEOUT_SECONDS and was abandoned.

busy

Every connection was serving the pipeline, so the measurement was skipped. Not a failure, and the figures shown are the last ones measured.

abandoned

The probe waited longer than one interval for a thread and was dropped before it ran. This is the probe pool, not the pipeline: raise GS_ENTITY_LAG_PROBE_CONCURRENCY or lengthen the interval. The figures shown are the last ones measured.

stale

No probe has completed for three of that entity’s sampling intervals, and the backlog figures are withheld. Substituted at scrape time for whatever the last completed probe said. Since a probe can only start on a CDC poll tick, this usually means the pipeline itself is stuck.

A figure a connector cannot produce is an absent series, never a zero. Zero is a legitimate backlog value that means caught up, so it cannot also stand for unknown, the way -1 does for gluesync_entity_dry_seconds. Read gluesync_entity_lag_probe_info to tell "this connector has no probe" from "the probe is failing", and do not fill a missing lag series with 0 in a dashboard or an alert.

Two further properties change how these series must be queried:

  • Figures older than three of that entity’s sampling intervals are not published at all, the cadence being the slower of the probe interval and the entity’s own polling interval. Because the lag is computed against now, a stale oldest-pending change would go on growing on an entity that may have caught up. Past the bound the backlog series disappear, result becomes stale, and gluesync_entity_lag_sample_age_seconds is what says why.

  • Every line carries an explicit timestamp. Prometheus does not mark an explicitly timestamped series stale when Core Hub stops exposing it, so after an entity is stopped or removed its last values stay queryable for the whole lookback window, five minutes by default. They stop moving, they do not vanish. Gate on the probe outcome instead of trusting the presence of a series:

    gluesync_source_lag_milliseconds{pipelineName=~"$pipelineName",entityName=~"$entityName"}
and on (pipelineId, entityId)
(gluesync_entity_lag_probe_info{result=~"ok|abandoned"} == 1)

abandoned belongs in the gate because it keeps the last measurement on purpose, unlike stale.

What a connector can measure differs widely. A trigger-based staging table gives an exact count for the price of one indexed COUNT(*), while a redo, binlog, or journal reader can only be counted by reading it, so several connectors report a time or a byte distance and no row count at all.

Example PromQL — worst backlog at each hop, across answering probes
# Source database to Gluesync
max(
  gluesync_source_lag_milliseconds
  and on (pipelineId, entityId)
  (gluesync_entity_lag_probe_info{result=~"ok|abandoned"} == 1)
)

# Local CDC cache to target
max(
  gluesync_cache_lag_milliseconds
  and on (pipelineId, entityId)
  (gluesync_entity_lag_probe_info{result=~"ok|abandoned"} == 1)
)
Example PromQL — entities whose probe is not answering
sum(gluesync_entity_lag_probe_info{result=~"error|timeout|busy|stale"}) or vector(0)

The or vector(0) matters: the probe emits every outcome on every scrape, so summing the failing ones returns a number rather than an empty result once any entity is being probed.

Entity lag is not gluesync_read_checkpoint_age_seconds. Checkpoint age is how long the persisted read position has stood still; entity lag is how far behind the source or the target the entity actually is, computed at scrape time from the oldest change that has not moved past that hop. The two families are deliberately kept apart, and only the lag families carry entity labels.

Database connection metrics

These gauges expose Core Hub’s live JDBC connection registry.

Metric Name Type Description

gluesync_db_connections_active

Gauge

Live borrowed connections attributed to an agent and purpose. Labels include agentId, agentName since 2.2.11.5, and purpose. This detail family can be absent when no connections are borrowed.

gluesync_db_connections_active_total

Gauge

Live borrowed connections aggregated by purpose. In 2.2.11, zero-valued series are emitted for pipeline_task, query_studio, query_forge_endpoint, and unspecified.

Known purposes are pipeline_task, query_studio, query_forge_endpoint, and unspecified. Rising ad-hoc query usage can indicate that Query Studio or Query Forge is competing with replication work for database capacity.

Core Hub also exposes standard HikariCP pool metrics. Useful KPIs include:

  • Pool utilization: hikaricp_connections_active / hikaricp_connections_max

  • Waiting borrowers: hikaricp_connections_pending

  • Average acquisition time: rate(hikaricp_connections_acquire_seconds_sum[$rate_interval]) / rate(hikaricp_connections_acquire_seconds_count[$rate_interval])

Sustained utilization near 1, especially with pending borrowers and rising acquisition time, indicates pool exhaustion.

Alert threshold configuration metrics

These metrics expose the active alert threshold configuration as Prometheus gauges. They are emitted once per scrape with no entity labels — they represent the global configuration applied to all pipelines.

Exposing thresholds as metrics enables Grafana to:

  • Show configured vs. observed values on the same panel

  • Trigger alerts when a metric approaches its threshold (e.g., latency at 80% of limit)

  • Record a history of threshold changes over time

Global Thresholds

Metric Name Type Description

gluesync_threshold_latency_minutes

Gauge

Static latency alert threshold in minutes. Only emitted when configured (not null).

gluesync_threshold_row_count_drift_percentage

Gauge

Row-count drift percentage threshold. Only emitted when configured (not null).

gluesync_threshold_pattern_detection_enabled

Gauge

1 when anomaly pattern detection is enabled globally, 0 when disabled.

gluesync_threshold_alert_cooldown_minutes

Gauge

Minimum quiet period between repeated alerts of the same type (minutes).

Data Flow Stall Detector

Metric Name Type Description

gluesync_threshold_data_flow_stall_enabled

Gauge

1 when stall detection is active, 0 when disabled.

gluesync_threshold_data_flow_stall_duration_minutes

Gauge

How many consecutive minutes of zero throughput trigger a stall alert.

gluesync_threshold_data_flow_stall_warmup_minutes

Gauge

Warm-up window excluded from stall detection after a pipeline starts (minutes).

Entity heartbeat watchdog

The heartbeat family exposes the source-inactivity watchdog configuration introduced for 2.2.11.

Metric Name Type Description

gluesync_threshold_entity_heartbeat_enabled

Gauge

1 when the entity heartbeat watchdog is enabled, 0 when disabled.

gluesync_threshold_entity_heartbeat_hard_floor_minutes

Gauge

Absolute inactivity ceiling before a hard-floor alert fires (minutes).

gluesync_threshold_entity_heartbeat_pattern_alert_minutes

Gauge

Pattern-aware inactivity threshold (minutes).

gluesync_threshold_entity_heartbeat_min_expected_changes_per_hour

Gauge

Minimum average changes per hour required for pattern-aware alerts.

gluesync_threshold_entity_heartbeat_warmup_occurrences

Gauge

Historical bucket observations required before pattern-aware alerting activates.

gluesync_threshold_entity_heartbeat_ewma_alpha

Gauge

EWMA smoothing factor used by the heartbeat watchdog.

gluesync_threshold_entity_heartbeat_max_silence_minutes

Gauge

Maximum silence before a heartbeat-missed alert fires (minutes).

These values are configuration gauges. Use gluesync_entity_dry_seconds, when emitted, as the observed inactivity measurement to compare with the configured limits.

Compatibility detector settings

The following gauges remain exposed for configuration compatibility and historical visibility. In current 2.2 smart-alert behavior, sensitivity is selected as Low, Normal, or High; nested EWMA, latency-pattern, and seasonal tuning values are retained on the wire but are not active detector controls.

Metric Name Type Description

gluesync_threshold_throughput_anomaly_enabled

Gauge

Configured throughput-anomaly toggle. The legacy EWMA detector does not currently fire alerts.

gluesync_threshold_throughput_smoothing_factor

Gauge

Configured legacy EWMA smoothing factor.

gluesync_threshold_throughput_control_multiplier

Gauge

Configured legacy EWMA control multiplier.

gluesync_threshold_throughput_min_data_points

Gauge

Configured legacy minimum sample count.

Compatibility latency-pattern settings

Metric Name Type Description

gluesync_threshold_latency_pattern_enabled

Gauge

Configured latency-pattern toggle. The legacy pattern detector does not currently fire alerts.

gluesync_threshold_latency_spike_multiplier

Gauge

Configured legacy spike multiplier.

gluesync_threshold_latency_sustained_multiplier

Gauge

Configured legacy sustained-latency multiplier.

gluesync_threshold_latency_sustained_window_minutes

Gauge

Configured legacy sustained window (minutes).

Compatibility seasonal settings

Metric Name Type Description

gluesync_threshold_seasonal_detection_enabled

Gauge

Configured seasonal-detection toggle. The legacy seasonal detector does not currently fire alerts.

gluesync_threshold_seasonal_min_days_history

Gauge

Configured legacy minimum history in days.

gluesync_threshold_seasonal_modified_z_score_threshold

Gauge

Configured legacy modified Z-score threshold.

Host and JVM metrics

System-level resource metrics emitted by the Gluesync host machine.

Metric Name Type Description

gluesync_system_uptime

Counter

Time since machine start. The 2.2.11 HELP text says milliseconds, but the emitted value is seconds.

gluesync_system_boot_time

Counter

Unix epoch time of last boot. The 2.2.11 HELP text says milliseconds, but the emitted value is epoch seconds.

gluesync_processor_cpu_load

Counter

Per-processor CPU load as a ratio from 0 to 1. Label: table

gluesync_system_cpu_load

Counter

Overall system CPU load as a ratio from 0 to 1

gluesync_cpu_interrupts

Counter

Total CPU interrupt count

gluesync_ram_total

Counter

Total RAM (megabytes)

gluesync_ram_available

Counter

Available RAM (megabytes)

gluesync_ram_page_size

Counter

OS memory page size (megabytes)

gluesync_network_interface_mb_received

Counter

Total data received per network interface (megabytes). Label: table

gluesync_network_interface_mb_sent

Counter

Total data sent per network interface (megabytes). Label: table

gluesync_network_interface_speed

Counter

Link speed per network interface (megabits/s). Label: table
CPU load, RAM, network speed, uptime, and boot time are declared as counters in 2.2.11 even though most are sampled state. Query them directly. Use rate() only for genuinely cumulative series such as interrupt count and network bytes.

Useful host queries:

# RAM currently in use
gluesync_ram_total - gluesync_ram_available

# Network receive rate per interface
rate(gluesync_network_interface_mb_received[$__rate_interval])

JVM runtime metrics

Standard Micrometer JVM families use their normal Prometheus types and base units.

Metric family Type Description

jvm_info

Gauge

Always 1; labels identify the JVM runtime, vendor, and version.

jvm_buffer_count_buffers

Gauge

Estimated buffer count by pool id.

jvm_buffer_memory_used_bytes

Gauge

Memory used by each buffer pool.

jvm_buffer_total_capacity_bytes

Gauge

Total capacity of each buffer pool.

jvm_gc_concurrent_phase_time_seconds

Summary

Concurrent GC phase duration. Prometheus exposes _count and _sum series with action, cause, and gc labels.

jvm_gc_concurrent_phase_time_seconds_max

Gauge

Maximum concurrent GC phase duration in the current publishing window.

jvm_gc_live_data_size_bytes

Gauge

Long-lived heap size after reclamation.

jvm_gc_max_data_size_bytes

Gauge

Maximum long-lived heap size.

jvm_gc_memory_allocated_bytes_total

Counter

Bytes allocated in the young heap between collections.

jvm_gc_memory_promoted_bytes_total

Counter

Positive increases in old-generation size across collections.

jvm_gc_overhead

Gauge

Approximate fraction of CPU time spent in garbage collection, from 0 to 1.

jvm_gc_pause_seconds

Summary

GC pause duration. Prometheus exposes quantiles plus _count and _sum.

jvm_gc_pause_seconds_max

Gauge

Maximum GC pause in the current publishing window.

jvm_memory_committed_bytes

Gauge

Memory committed by area and pool id.

jvm_memory_max_bytes

Gauge

Maximum memory by area and pool. -1 means no defined maximum.

jvm_memory_usage_after_gc

Gauge

Long-lived heap fraction used after the latest GC, from 0 to 1.

jvm_memory_used_bytes

Gauge

Current memory usage by area and pool id.

jvm_threads_daemon_threads

Gauge

Current live daemon threads.

jvm_threads_live_threads

Gauge

Current live daemon and non-daemon threads.

jvm_threads_peak_threads

Gauge

Peak live thread count since JVM start or peak reset.

jvm_threads_started_threads_total

Counter

Total application threads started.

jvm_threads_states_threads

Gauge

Current threads by state.

The official dashboard uses:

  • jvm_memory_used_bytes{area="heap"} for heap usage by pool

  • rate(jvm_gc_pause_seconds_sum[$rate_interval]) / rate(jvm_gc_pause_seconds_count[$rate_interval]) for average GC pause

  • jvm_threads_live_threads for live thread count

An Eden heap sawtooth is normal. Old-generation usage that continues rising without falling after garbage collection can indicate retained objects. Interpret GC pause and thread count together with heap behavior and host CPU.

Ktor HTTP server metrics

Metric family Type Description

ktor_http_server_requests_active

Gauge

HTTP requests currently being processed.

ktor_http_server_requests_seconds

Summary

Request duration in seconds. Exposes configured quantiles and the _count and _sum series.

ktor_http_server_requests_seconds_max

Gauge

Maximum request duration in the current publishing window.

Request-duration labels are address, method, route, status, and throwable. Prefer the normalized route label for endpoint analysis. The address label can split traffic by the hostname used by internal and external callers.

Example PromQL — request rate by route and status
sum by (route, status) (
  rate(ktor_http_server_requests_seconds_count[$__rate_interval])
)
Example PromQL — average request duration by route
sum by (route) (
  rate(ktor_http_server_requests_seconds_sum[$__rate_interval])
)
/
sum by (route) (
  rate(ktor_http_server_requests_seconds_count[$__rate_interval])
)
route, status, method, address, and throwable create separate time series. Aggregate away labels that are not needed, and avoid alerts over unrestricted combinations.

HikariCP pool metrics

HikariCP metrics are conditional and may be absent when no instrumented pool has registered. Common families used by the official dashboard include hikaricp_connections_active, hikaricp_connections_max, hikaricp_connections_pending, and the hikaricp_connections_acquire_seconds summary.