Use `obdiag check` commands to inspect an OceanBase cluster

If OceanBase Diagnostic Tool (obdiag) is independently deployed, you can use obdiag check commands to inspect the status of an OceanBase cluster. The inspection process analyzes the cluster from perspectives of the system kernel parameters and internal tables, identifies the causes of existing or possible exceptions, and provides O&M suggestions.

Prerequisites

You have installed obdiag. For more information, see Install obdiag.

check commands

Syntax

obdiag check [options]

The following table describes the options.

Here is an example:

obdiag check --cases=test

'cat ./check_report/check_report_2023-10-30-16:15:52.table', export type is table
For more details, please run cmd 'cat ./check_report/check_report_2023-10-30-16:15:52.table'
If you want to view detailed obdiag logs, please run:'obdiag display-trace --trace_id a7674ecb-0d99-36fe-b584-3b707b4647bc'

Tutorial for writing a task

A task is a script file written in YAML, which defines an independent inspection scenario.

Each task contains a forward declaration for professional inspection.

Preparation

Before you write a task script file, determine where you want to save it.

The script file must be saved in the CHECK.tasks_base_path directory specified in the config.yml file. Make sure that you have a folder in this directory to describe your inspection scenario.

Here is an example:

# Go to the `${CHECK.tasks_base_path}` directory, create a folder named `test`, and then create a sample task script file named `test.yaml`.
cd ~/.obdiag/tasks/
mkdir test
cd test
touch test.yaml

Write a task script

A task script declares a list of steps to be executed for inspection. Some inspection items may not be properly used or some steps may not be performed as expected in different OceanBase Database versions. In this case, you can include them in a task script.

Here is a sample task file:

info: testinfo
task:
  - obversion: "[3.1.0,3.2.4]"
    steps:
      {steps_object}
  - obversion: "[4.2.0.0,4.3.0.0]"
    steps:
      {steps_object}

The parameters are described as follows:

About steps

steps is a list of multiple execution processes.

An element of steps is a single process that contains the following parameters:

In the following examples, step: serves only as a mark and has no actual meaning.

• get_system_parameter

  steps:
  - type: get_system_parameter
    parameter_name: parameter
    result:
      set_value: servervm.max_map_count
  

• ssh

  Remotely execute the instruction and obtain the corresponding return value

  steps:
  - type: ssh
    ssh: wc -l /proc/${task_OBServer_pid}/maps | awk '{print $1}'
    result:
      set_value: observerMaps
  

• sql

  Execute an SQL statement and obtain the corresponding value.

  steps:
  - type: sql
    sql: select tenant_name from oceanbase.table_name from where tenant_id=${taskTenantId};
    result:
      set_value: tenant_name
  

result & verify

This field is the main dependent field of the verify feature and is used to verify the task result.

The syntax is as follows:

result:
      set_value: {set_value}
      verify_type: {verify_type}
      report_type: {report_type}
      verify: {verify}
      err_msg: {err_msg}

The parameters are described as follows:

Judgment types supported by verify_type:

At present, the judgment types supported by verify_type apply only the base and int types.

• between: checks whether the set_value value is within the range provided by verify.
• max: checks whether the set_value value is less than the value provided by verify.
• min: checks whether the set_value value is greater than the value provided by verify.
• equal: checks whether the set_value value is equal to the value provided by verify.

About base

verify expressions are used to replace the verification in the following shell expression new_expr. When you write verify, you can manually verify the logic on a local server.

if ${new_expr}; then
    echo "true"
else
    echo "false"
fi

About manual update of tasks

To provide more effective inspection tasks, we will update these tasks from time to time. You can replace the ~/.obdiag/tasks folder and the ~/.obdiag/check_package.yaml with the tasks folder and the check_package.yaml file under the ${code_path}/handler/check directory in obdiag code repository to update them.