The first time you run gha_ctl monitor all, the output can look overwhelming. It is tempting to scroll to the last line and assume that the summary tells the whole story.

But GBase Database(GBase 8c) organizes its cluster monitoring output into four component tables plus a DCS health list. Each section answers a different operational question.

Understanding these sections makes database troubleshooting faster and helps engineers identify problems at the correct layer.

1. The Four Monitoring Tables

Run the following command:

gha_ctl monitor all -l http://<dcs>:2379 -H

The -H option prints column headers, making the output easier to read manually.

Here is what to check in each section.

gha_server: Is There a Management Leader?

Check the leader column.

At least one instance should report True. This identifies the management leader responsible for coordinating cluster operations.

Without a management leader, subsequent management operations may be affected.

gtm: Are Transaction Management Roles Correct?

Check both the role and state columns.

The expected arrangement is:

  • One primary instance
  • One standby instance
  • Both instances running

A correct role relationship matters as much as process availability.

coordinator: Are All CN Instances Running?

Check the coordinator section.

All CN (Coordinator) instances should be running with the primary role.

Unlike DataNodes, CN instances do not replicate data between themselves. They serve as parallel SQL entry points, so their expected role distribution is different.

datanode: Does Every Group Have Exactly One Primary?

This is one of the most important sections.

For each DN (DataNode) group, verify:

  • Exactly one primary
  • All remaining replicas in standby
  • All expected instances running

Two primaries indicate an incorrect role relationship. Zero primaries mean the group has no writable node.

When an application cannot connect or execute queries, checking this section early can prevent unnecessary troubleshooting at the network or authentication layer.

2. Do Not Skip the DCS Health List

After reviewing the four component tables, check the DCS health list.

Every DCS node should be healthy, with exactly one node identified by isLeader.

GBase Database relies on DCS for quorum and cluster coordination. If DCS is unhealthy or has no leader, the role information reported by higher-level components cannot be trusted without further investigation.

The recommended reading order is:

DCS → gha_server → GTM → CN → DN

This follows the cluster dependency chain and helps narrow down the source of a problem.

For example, an application connection failure might initially look like a network or authentication issue. But if a DN group has no primary, investigating firewall rules for two hours will not solve the underlying problem.

Check cluster state before moving to higher-level troubleshooting.

3. A Note About the -H Option

The command includes:

gha_ctl monitor all -l http://10.x.x.6:2379 -H

The -H option prints headers, which makes manual inspection easier.

For automated monitoring or scripts, avoid parsing the output using fixed line numbers.

The number of instances can vary depending on the deployment layout. Parse the output by component section and identify the relevant fields instead.

This makes monitoring scripts more resilient to topology changes.

4. Turn Monitoring Output into Acceptance Evidence

The monitoring output is useful for more than troubleshooting.

It can also become part of the GBase Database deployment acceptance record.

Instead of documenting only that the cluster was checked, archive the actual output.

This provides several benefits:

  • Verifiable evidence of component states and roles
  • A baseline for future maintenance
  • Easier comparison after restarts or topology changes
  • More reliable handover between engineering teams

Because GBase Database monitoring output is structured by component, it is relatively easy to archive and review.

Key Takeaway

Reading gha_ctl monitor all is not about memorizing a command. It is about understanding what each component reports and in which order to investigate it.

Start with DCS, then check gha_server, GTM, CN, and DN. This dependency-based approach helps engineers distinguish cluster problems from connection problems and makes GBase Database monitoring more useful for both daily operations and deployment acceptance.