This article applies to the scenario of independently deploying obdiag. Using the obdiag display command can help gain insight into information related to the OceanBase database.
View currently supported scenarios
obdiag display scene list
obdiag display scene run use
obdiag display scene run --scene={SceneName}
The options are explained below:
Option name |
Is it required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| --scene | Yes | string | Default is empty | Scene name, you can view the scenes supported by the current version through obdiag display scene list. |
| --from | No | string | Default is empty | Starting point of time range, format: yyyy-mm-dd hh:mm:ss. Will be used in some scenarios (such as merge state). |
| --to | No | string | Default is empty | End of time range, format: yyyy-mm-dd hh:mm:ss. |
| --since | No | string | 30m |
The time range relative to the current time, format: <n><m|h|d>, where n represents the time number to be entered, m represents minutes, h represents hours, and d represents days, such as 1h represents the last hour. |
| --env | No | string | Default is empty | Additional parameters required by some scenarios, format: --env key=value, can be specified multiple times. |
| -c | No | string | ~/.obdiag/config.yml |
Configuration file path. |
| --inner_config | No | string | Default is empty | obdiag Self-configuration, format: --inner_config key=value. |
| --config | No | string | Default is empty | Cluster configuration, format: --config key1=value1 --config key2=value2. See obdiag configuration for details. |
| --config_password | No | string | Default is empty | obdiag When using an encrypted configuration file, you need to pass in the corresponding password through this option. For details, see Configuration File Encryption. |
Description
obdiag display does not put information on the disk, but only displays a black screen. Starting from V4.0.0, the merge status display scene observer.compaction is supported, which can be used through obdiag display scene run --scene=observer.compaction. The clog log volume/capacity statistics scene observer.clog_volume_statistics is supported starting from V4.1.0, which can be used through obdiag display scene run --scene=observer.clog_volume_statistics.
Usage example
Method 1: Use without configuration file (out of the box)
obdiag display scene run --scene={SceneName} \
--config db_host=xx.xx.xx.xx \
--config db_port=xxxx \
--config tenant_sys.user=root@sys \
--config tenant_sys.password=***
Method 2: Use with configuration file
You need to ensure that the login information of the node to be collected has been configured in the obdiag configuration file config.yml. For related detailed configuration introduction, see obdiag configuration.
obdiag display scene run --scene={SceneName}
Custom scene writing tutorial
A task represents an independent scenario, which can be understood as a professional script file written in yaml and recognized by obdiag.
Before starting to write
First enter ${display.scenes_base_path} and create our sample file test.yaml (taking the OceanBase database as the test target):
cd ~/.obdiag/display/tasks/observer
touch test.yaml
The above completes the steps before writing
Start writing
To start writing we start editing our test.yaml.
# Describe what this scenario does (human-readable summary)
info: "for test"
Simple content is over, complex writing begins, pay attention to details
Scene writing
The function of task is to declare the steps for scene collection execution. In order to be compatible with the differences in steps that may occur in different versions, its basic structure is a list.
The structure of an element of task is as follows
Parameter name |
Is it required |
Description |
Data type |
|---|---|---|---|
| version | No | Indicates the applicable version, see the following example for usage | Use the form of str to represent the range, which requires a complete digital version number. The 3.x version is three digits, and the 4.x version is four digits, such as: [3.1.1,3.2.0]. The version support follows the principle of left open and closed. |
| steps | Yes | The steps performed | are list structures. |
Examples are as follows:
info: testinfo
task:
- version: "[3.1.0,3.2.4]"
steps:
{steps_object}
- version: [4.2.0.0,4.3.0.0]
steps:
{steps_object}
steps is another list, used to represent multiple specific execution processes.
The structure of an element of steps is a single process, with the following content:
Parameter name |
Is it required |
Description |
|---|---|---|
| type | Yes | indicates the applicable execution type. Currently, only SQL is supported, and supported types will continue to be added in the future. |
| {sql} | Yes | Parameters provided based on the selected type. This section relies more on the logical description of the execution type in the code. This chapter will provide detailed instructions for the supported execution types later in this chapter. |
Examples of various types are as follows. step: is just a mark and has no practical effect.
sql
Execute SQL and get the corresponding value:
step:
type: sql
sql: select tenant_name from oceanbase.__all_tenant;
global: false
```<main id="notice" type='explain'>
<h4>Description</h4>
<p> The Global field is relative to the node. When marked as <code>true</code>, it will only be executed once when the first node is executed. If marked as <code>false</code>, it will be executed on each node. </p>
</main>