Skip to content

Create monitor.md #111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
50 changes: 50 additions & 0 deletions commands/monitor.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
title: "MONITOR"
nav_order: 110
description: >
Allows to observe all requests processed by the database in real-time.
parent: "Commands"
---

# MONITOR

Allows to observe all requests processed by the database in real-time.
This feature is invaluable for debugging and understanding the sequence of operations occurring in the database.

Usage: `MONITOR`

## Example

```
> MONITOR
```

## Output

```sh
1673022405.123456 [0 127.0.0.1:6379] "GRAPH.QUERY" "MyGraph" "MATCH (n) return n"
1673022405.123789 [0 127.0.0.1:6379] "GRAPH.DELETE" "MyGraph"
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example isn't very clear:

  1. How does the user supposed to issue the MONITOR command?
  2. From where dod the GRAPH.* commands came from ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Example

> MONITOR
  1. it says output


Each line includes the following:

1. **Timestamp:** The precise time when the command was received.
2. **Database Index:** The database number where the command was executed (e.g., `[0]`).
3. **Client Info:** The IP address and port of the client that issued the command.
4. **Command:** The exact command and its arguments.

## Considerations

- **Security:** Ensure `MONITOR` is used only by trusted users. It exposes all incoming commands, including potentially sensitive data.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ensure ? who's suppose to ensure that? and how exactly ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are things for Considerations

- **Overhead:** `MONITOR` can slow down the database, especially under high load, due to the additional I/O required to stream the logs.
- **Connection Restriction:** Typically, `MONITOR` should be run from a dedicated connection. Mixing it with other commands can result in undefined behavior.

## Terminating MONITOR

To stop the `MONITOR` stream, simply close the client connection (e.g., terminate the session or disconnect the client tool).

## Best Practices

- Use `MONITOR` sparingly in production environments.
- Combine `MONITOR` with logging or analysis tools for deeper insights.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shallow, unless we give recommendations for such tools.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took it from Redis docs

- Restrict access to users who require diagnostic capabilities, see: [ACL](/commands/acl) for more details.
Loading