CRR Monitoring
Starting from TigerGraph 4.3, the Disaster Recovery (DR) cluster supports Cross-Region Replication (CRR) status, metrics collection and query capabilities.
The CRR metrics collection interval can be configured using the following command (default: 60s):
gadmin config entry System.Metrics.CRRIntervalSec
1. CLI-based CRR status query
Users can run a gadmin command to get detailed CRR metrics.
gadmin crr status [flags]
The command provides comprehensive CRR status information, including:
-
Overall CRR system status
-
Topic replication and replay lag
-
MirrorMaker 2 connector status
1.1. Flags
The following flags can be used with the gadmin crr status command.
| Flag | Description |
|---|---|
|
Outputs CRR status in JSON format. |
|
Retrieves real-time status instead of cached data. |
|
Displays detailed metrics, including source and target offsets and timestamps. |
1.2. CRR Topic Metrics
The following table provides the definitions of topic metrics.
| Field Name | Description | Notes | Shown When |
|---|---|---|---|
|
Number of records the DR topic is behind the corresponding PR topic. |
Calculated as |
always |
|
Number of records the replay process in DR is behind the replicated topic. |
Calculated as |
always |
|
Time lag in seconds between the latest record in PR and its replication in DR. |
Calculated as |
always |
|
Time lag in seconds between the latest record in DR and its replay. |
Calculated as |
always |
|
Duration in seconds that replication from PR to DR has made no forward progress. |
0 means replication is actively progressing. |
always |
|
Duration in seconds that replay within DR has made no forward progress. |
0 means replay is actively progressing. |
always |
|
Latest offset available in the PR Kafka cluster. |
Highest offset produced in the PR topic. |
--verbose |
|
Offset up to which data has been replicated from PR to DR. |
Highest offset confirmed written to the DR topic. |
--verbose |
|
Latest offset available in the DR Kafka topic. |
Highest offset physically present in the DR topic. |
--verbose |
|
Offset up to which the replay service in DR has processed records. |
Highest offset successfully replayed in DR. |
--verbose |
|
Timestamp of the record at |
Based on Kafka message timestamp. |
--verbose |
|
Timestamp of the record at |
Based on Kafka message timestamp. |
--verbose |
|
Timestamp of the record at |
Based on Kafka message timestamp. |
--verbose |
|
Timestamp of the record at |
Based on Kafka message timestamp. |
--verbose |
2. OpenMetrics Integration
CRR topic metrics can also be collected in OpenMetrics format using the following API:
curl http://localhost:14240/informant/metrics
The following table defines the CRR metrics available in OpenMetrics format.
| Type | Name | Label | Description |
|---|---|---|---|
Metric |
|
topic |
Replication lag (records) |
Metric |
|
topic |
Replay lag (records) |
Metric |
|
topic |
Replication lag (seconds) |
Metric |
|
topic |
Replay lag (seconds) |
Metric |
|
topic |
Duration replication has stalled |
Metric |
|
topic |
Duration replay has stalled |
Metric |
|
topic |
Source offset in PR |
Metric |
|
topic |
Replicated offset in DR |
Metric |
|
topic |
Target offset in DR topic |
Metric |
|
topic |
Replayed offset in DR |
Metric |
|
topic |
Timestamp of source record in PR |
Metric |
|
topic |
Timestamp of replicated record in DR |
Metric |
|
topic |
Timestamp of target record in DR |
Metric |
|
topic |
Timestamp of replayed record in DR |
|
TigerGraph provides raw metrics for CRR topic Replication and Replay, but does not include built-in alerting. Replication and replay lag may vary depending on cluster configuration, network bandwidth, and latency. Users are advised to define alerting rules in their own monitoring systems (for example, Prometheus). For example, a CRR topic can be considered abnormal if any of the following conditions occur:
These thresholds can be adjusted according to the environment and operational requirements. |