# HiSysEvent Logging Configuration ## Overview ### Function Introduction If HiSysEvent logging is required for a component, you need to define a YAML file and [configure the YAML file path](#verifying-the-yaml-file) in the **bundle.json** file. During compilation, the OpenHarmony compilation framework will use the Python compilation script to parse and verify all the YAML files configured in the **bundle.json** file. On completion, the compilation framework will summarize the configuration information in the YAML files and convert the information into a JSON file named **hisysevent.def**. After that, the compilation framework will put the JSON file to a specified path as the basis for the system to determine whether to log system events. ### Basic Concepts Understanding the following concepts would be helpful for you in configuring HiSysEvent logging. - Event domain
Represents the domain to which an event belongs. It is specified by the **domain** field in the YAML file. For details, see [domain](#writing-a-yaml-file) in the example YAML file. - Event name
Indicates the events in an event domain. For details, see [EVENT\_NAMEA/EVENT\_NAMEB](#writing-a-yaml-file) in the example YAML file. - Parameter
Defines the key values in an event name. For details, see [__BASE/NAME1/NAME2](#writing-a-yaml-file) in the example YAML file. ### Constraints Constraints on the event domain, event name, and parameter - Each YAML file can contain only one event domain, and the domain name cannot be the same as that defined in other YAML files. - Zero or more event names can be defined for one event domain. The event names in the same event domain must be unique. - Multiple parameters can be defined for one event name. The parameters in the same event name must be unique. There must be only one parameter named **__BASE** in each event name. See Table 1 for the fields of this parameter and Table 2 for the fields of other custom parameters. **Table 1** Fields in the \__BASE parameter | Field| Description| | -------- | -------- | | type | Event type. This field is mandatory.
Value:
- FAULT: fault
- STATISTIC: statistics
- SECURITY: security
- BEHAVIOR: user behavior| | level | Event level. This field is mandatory.
Value:
- CRITICAL: critical
- MINOR: minor| | tag | Event tag. This field is mandatory.
Rule:
- You can define a maximum of five tags, separated with a space.
- A single tag can contain a maximum of 16 characters, including a to z, A to Z, and 0 to 9.| | desc | Event name. This field is mandatory.
Rule:
The description contains 3 to 128 characters, including a to z, A to Z, 0 to 9, and underscores (_).| **Table 2** Description of custom parameters | Field| Description| | -------- | -------- | | type | Parameter type. This field is mandatory.
Value:
- BOOL
- INT8
- UINT8
- INT16
- UINT16
- INT32
- UINT32
- INT64
- UINT64
- FLOAT
- DOUBLE
- STRING | | arrsize | Length of the parameter of the array type. This field is optional.
Value:
1-100| | desc | Parameter description. This field is mandatory.
Rule:
The description contains 3 to 128 characters, including a to z, A to Z, 0 to 9, and underscores (_).| ## How to Develop ### Writing a YAML File **Writing Rules** - Event domain naming rules: - The name must start with a letter and can contain only uppercase letters, digits, and underscores (_). - The name contains 1 to 16 characters. - Event naming rules: - The name must start with a letter and can contain only uppercase letters, digits, and underscores (_). - The name contains 1 to 32 characters. - The number of internal event names in an event domain cannot exceed 4096. - Parameter naming rules: - The name must start with a letter and can contain only uppercase letters, digits, and underscores (_). - The name contains 1 to 48 characters. - The number of parameters in an event domain cannot exceed 128. **Example** - In the example YAML file, the event domain name is **MODULEA**. The event domain contains two events named **EVENT_NAMEA** and **EVENT_NAMEB**. - **EVENT\_NAMEA** is defined as a critical event of the fault type. The event contains the **NAME1** parameter of the string type, the **NAME2** parameter of the string type, and the **NAME3** parameter of the unsigned short integer type. Therefore, you can perform [real-time subscription](../subsystems/subsys-dfx-hisysevent-listening.md) to the event based on the event domain **MODULEA** and event name **EVENT\_NAMEA**. - **EVENT\_NAMEB** is defined as a general event of the statistics type. The event contains the **NAME1** parameter of the unsigned short integer type and the **NAME2** parameter of the integer type. Because two event tags named **tag1** and **tag2** are defined for **EVENT\_NAMEB** in the **\__BASE** parameter, you can perform [real-time subscription](../subsystems/subsys-dfx-hisysevent-listening.md) to the event based on the event domain **MODULEA** and event name **EVENT\_NAMEB**, or based on the event tag. ``` ########################################## # the hisysevent definition for module a # ########################################## domain: MODULEA EVENT_NAMEA: __BASE: {type: FAULT, level: CRITICAL, desc: event name a} NAME1: {type: STRING, desc: name1} NAME2: {type: STRING, desc: name2} NAME3: {type: UINT16, desc: name3} EVENT_NAMEB: __BASE: {type: STATISTIC, level: MINOR, tag: tag1 tag2, desc: event name b} NAME1: {type: UINT16, desc: name1} NAME2: {type: INT32, desc: name2} ``` ### Verifying the YAML File **Configuring the YAML File Path** In the **bundle.json** file, use the **hisysevent_config** attribute to specify the YAML file path. ``` { "name": "@ohos/moduel_a", "description": "module a", "version": "3.1", "license": "Apache License 2.0", "publishAs": "code-segment", "segment": { "destPath": "moduel_a_path" }, "dirs": {}, "scripts": {}, "component": { "name": "hisysevent_native", "subsystem": "hiviewdfx", "adapted_system_type": [ "standard" ], "rom": "", "ram": "", "hisysevent_config": [ "//moduel_a_path/yaml_file1.yaml", "//moduel_a_path/yaml_file2.yaml" ], "deps": { "components": [ "hilog_native", "hitrace_native", "ipc", "safwk", "samgr", "utils_base" ], "third_party": [] }, "build": { } } } ``` > **NOTE**
> The YAML file can be placed in any directory of the component project as needed. You only need to specify the path in the **bundle.json** file. **Compiling YAML Files** - Perform full compilation. - During full compilation of the system, the configurations in the YAML files of all components are summarized. After the compilation is complete, the **hisysevent.def** file will be generated in the specified directory. ``` cd *absolute path of the project's root directory* ./build --product-name ``` - To obtain the **hisysevent.def** file generated after full compilation, run the following commands: ``` cd absolute path of the project's root directory find out -name hisysevent.def -type f ``` - Single-file compilation: You can also compile the YAML file of a single component by running the following commands: ``` cd absolute path of the project's root directory ./build/ohos/hisysevent/gen_def_from_all_yaml.py --yaml-list --def-path ``` **Table 3** Parameters for single-file compilation | Option| Description| | -------- | -------- | | --yaml-list | Paths of the YAML files to be compiled. If there are multiple YAML file paths, separate each of them with a space.| | --def-path | Path of the **hisysevent.def** file generated after compilation.| ### Logging and Querying Events 1. Push the **hisysevent.def** file to the **/system/etc/hiview/** directory of the device by using the [hdc_std tool](../subsystems/subsys-toolchain-hdc-guide.md). 2. Trigger logging of the custom system events in the YAML file. Then, run [hisysevent -l](../subsystems/subsys-dfx-hisysevent-tool.md) to query historical system events to find out if the logging of the custom system events is successful.