# Neo4j Database Monitor Configuration Guide on the Elven Platform

The **Neo4j Monitor** from the **Elven Platform** enables checks based on **key queries** in **Neo4j**. This feature helps configure **continuous checks**, define **alerts**, and set **thresholds** for **automatic incident opening**, ensuring you are quickly informed about any **connectivity** or **performance issues**.

**Neo4j** is an **open-source graph database** designed to store and query **highly connected data**. It uses a **graph model**, where data is represented as **nodes**, **relationships**, and **properties**, making it easier to model and analyze **complex, interrelated data**.

**Neo4j** is widely used in scenarios such as **social networks**, **personalized recommendations**, **fraud detection**, and **network management systems**, due to its efficiency in executing **complex graph queries** with **high performance**. With advanced features like **transaction support**, **scalability**, and **real-time querying**, **Neo4j** is ideal for applications that require **large-scale relationship analysis**, offering a **flexible** and **high-availability solution** for **dynamic and interconnected environments**.

## **Accessing Neo4j Monitoring**&#x20;

* Navigate to the **main menu** and click on **Services Hub**.
* Under **Database**, select the **Neo4j** item.

<figure><img src="https://content.gitbook.com/content/NbD6tAAcbxaY8pw1cchL/blobs/WYY5iDAfgQC8DOC6ACRZ/neo4jm01.png" alt=""><figcaption></figcaption></figure>

## **Monitoring Configuration**

**Monitoring the availability of your services** has never been easier. Start by giving a clear **Resource Name** to the item you want to monitor, making it easier to identify. Then, adjust the **Interval** between checks and the **Timeout** for responses.

Select where the **monitoring agent** is located (**Checkpoint Cloud**) by choosing an existing **Environment**, or create a new one by clicking **+ Checkpoint**. After this setup, enter the server address in the **Host** field and specify the **Port**. In **User** and **Password**, provide the username and password, which are the **access credentials** for the database.

Keep in mind that the **Host** field only accepts **URLs**; if you need to use an **IP address**, it must be created in a **Secret** to ensure the **security** and **organization** of the information.

<figure><img src="https://content.gitbook.com/content/NbD6tAAcbxaY8pw1cchL/blobs/qvK1UQIRHD8nX28Npsy1/neo4jm02.png" alt=""><figcaption></figcaption></figure>

## **Automatic Incident Opening**

You can configure **automatic incident opening** to ensure a quick response to critical issues. To begin, define the **incident severity**, allowing you to prioritize according to urgency. Next, adjust the **Check Interval**, specifying the check frequency in seconds to continuously monitor the resource. This helps ensure you're always one step ahead, detecting problems as soon as they arise.

Additionally, select the **team to be notified** whenever an incident occurs and enable the **"Enable to set up automatic incidents opening"** option to ensure the configuration is active. With this setup, the platform automates **incident management**, making the response process faster and more efficient, without the need for manual intervention. This ensures your team is always ready to resolve any issue with speed and precision.

<figure><img src="https://content.gitbook.com/content/NbD6tAAcbxaY8pw1cchL/blobs/cJhynwQcWMKFObXEqIb2/neo4jm03.png" alt=""><figcaption></figcaption></figure>

## **Maintenance Window**

We also have the **Maintenance Window**, an essential feature for managing **planned maintenance periods** in your application. During this interval, **checks are temporarily paused**, preventing **monitoring**, **alerts**, and **notifications** from being triggered while you perform updates or adjustments. This allows maintenance to proceed smoothly, without generating unnecessary notifications or false alarms, ensuring your operation continues in an orderly manner without unexpected interruptions in **performance reports**.

For example, imagine you need to update the **payment system** of an e-commerce platform by making backend adjustments, such as installing new **security certificates**. To do this, you can configure the **Maintenance Window** for a specific time, such as **12/13/2024, from 2:00 PM to 2:30 PM**. During this period, the **Elven Platform** suspends checks, preventing the monitoring system from recording temporary failures or triggering false alerts. This way, you can make the necessary changes calmly, knowing that the **monitoring system** will not be impacted during maintenance. This approach ensures that the update is carried out in an organized manner, without affecting the **user experience** or generating unwanted **notifications**.

<figure><img src="https://content.gitbook.com/content/NbD6tAAcbxaY8pw1cchL/blobs/r2FYF3AGvug4mVHevN5q/neo4jm04.png" alt=""><figcaption></figcaption></figure>

## **Application Opening Hours**

You can also rely on the **Application Opening Hours** feature, which allows you to configure your application's **operating hours**. This functionality is essential for customizing **monitoring** based on the periods when your application is actually active, avoiding **alerts** and **notifications** outside of business hours. This way, monitoring becomes more aligned with your business’s real needs, ensuring more accurate **reports** and efficient **management**.

For example, imagine your application operates only from **Monday to Friday, from 9:00 AM to 6:00 PM**. You can configure **Application Opening Hours** to reflect this schedule by specifying the **days** and **time periods** of operation. With this setup, the **Elven Platform** automatically disables checks outside these hours, preventing the logging of failures that do not affect end users and avoiding unnecessary alerts. This approach optimizes **performance analysis**, focusing only on relevant periods and providing a clearer view of your application's **health** during its **operating hours**.&#x20;

<figure><img src="https://content.gitbook.com/content/NbD6tAAcbxaY8pw1cchL/blobs/T4GTcbWd0DSCyzCZbHmz/neo4jm05.png" alt=""><figcaption></figcaption></figure>

## **Glossary of Technical Terms**

**Neo4j**: An **open-source NoSQL graph database** designed to store and query **highly connected data** using a **graph model**. By utilizing **nodes**, **relationships**, and **properties**, Neo4j enables efficient modeling and analysis of **complex data**, making it ideal for applications involving **social networks**, **recommendation systems**, **fraud detection**, and **network management**. Known for its **high performance** in **complex graph queries** and **scalability**, Neo4j is widely adopted in scenarios that require **real-time connection analysis**, offering **high availability** and **flexibility** for **dynamic environments**.

**Interval**: The **time interval** between automatic checks performed during monitoring.

**Timeout**: The **maximum time** allowed for the monitoring system to receive a response from the monitored resource before registering a failure.

**Checkpoint Cloud**: The **location** where the **monitoring agent** is hosted, which can be a pre-existing environment or one created by the user.

**Host**: The **URL address** of the monitored resource. If an **IP address** is required, it must be stored in a **Secret** to ensure **security**.

**Secret**: A resource used to store **sensitive information**, such as IP addresses or credentials, ensuring **security** and **organization**.

**Enable to set up automatic incidents opening**: An option that, when enabled, allows the **automatic creation of incidents** upon detection of **critical issues**.

**Severity**: The **level of criticality** assigned to an incident, allowing it to be prioritized based on **urgency**.

**Check Interval**: The **time interval**, in seconds, for performing **continuous checks** on the monitored resource.

**Maintenance Window**: A feature that **temporarily pauses monitoring**, **alerts**, and **notifications** during **planned maintenance periods**.

**Application Opening Hours**: A configuration that defines the **operating hours** of the application, aligning monitoring with **active periods** and avoiding alerts outside those hours.
