Previous Next JavaScript must be enabled to correctly display this content

## Events

Events are special messages that inform you of the state of your system. As events are generated, they are routed through the monitoring system so that you can see them. There are four types of events that the store reports:

1. State Change events are issued when a service starts up or shuts down.

2. Performance events report statistics about the performance of various services.

3. Log events are records produced by the various system components to provide trace information about debugging. These records are produced by the standard `java.util.logging` package.

4. Plan Change events record the progress of plans as they execute, are interrupted, fail or are canceled.

Note:

- Some events are considered critical. These events are recorded in the administration service's database, and can be retrieved and viewed using the CLI.
- You can compress the log event records that are produced by the standard `java.util.logging` package. For more information, see Log File Compression.

You cannot view Plan Change events directly through Oracle NoSQL Database's administrative interfaces. However, State Change events, Performance events, and Log events are recorded using the EventRecorder facility, which is internal to the Admin. Only events considered critical are recorded, and the criteria for being designated as such varies with the event type. These are the events considered critical:

- All state changes.
- Log events classified as `SEVERE`.
- Any performance events reported as below a certain threshold.

You can view all of these critical events using the Admin CLI `show events` and `show event` commands.

Use the CLI `show events` command with no arguments to see all of the unexpired events in the database. Use the `-from` and `-to` arguments to limit the range of events that display. Use the `-type` or `-id` arguments to filter events by type or id, respectively.

For example, this is part of the output from a `show events` command:

    kv-> show events

Output:

    idarpdfbS STAT 2024-04-05 22:18:39.287 UTC sn1 RUNNING sev1
    idarpeg0S STAT 2024-04-05 22:18:40.608 UTC sn2 RUNNING sev1
    idarphmuS STAT 2024-04-05 22:18:44.742 UTC rg1-rn1 RUNNING sev1
    idarpjLLS STAT 2024-04-05 22:18:47.289 UTC rg1-rn2 RUNNING sev1
    idartfcuS STAT 2024-04-05 22:21:48.414 UTC rg1-rn2 UNREACHABLE sev2
                                                       (reported by admin1)

This result shows four service state change events (`sev1`) and one log event (`UNREACHABLE`), classified as `sev2`. Tags at the beginning of each line are individual event record identifiers. To see detailed information for a particular event, use the `show event` command, which takes an event record identifier, such as `idartfcuS` as its argument:

    kv-> show event -id idartfcuS

Output:

    idartfcuS STAT 2024-04-05 22:21:48.414 UTC rg1-rn2 UNREACHABLE sev2
      (reported by admin1)

Using this method of event identifiers, you can see a complete stack trace.

Events are removed from the system if the total number of events is greater than a set maximum number, or if the Event is older than a set period. The default maximum number of events is 10,000, while the default time period is 30 days.

Both `Sev1` and `Sev2` flags are associated with specific service state change events. `Sev1` flags report the current state. `Sev2` flags report errors during attempted state changes, as follows:

Sev1 Flags | Sev2 Flags
--- | ---
`STARTING` | `ERROR_RESTARTING`
`WAITING_FOR_DEPLOY` | `ERROR_NO_RESTART`
`RUNNING` | `UNREACHABLE`
`STOPPING` |
`STOPPED` |