There is an example script below for simple monitoring, pressing 1 or 2 to send OK or Failure.

The purpose of this example is just to demonstrate how calls should be made for monitoring, via webhook, created by the platform.

 

Example:

				
					Write-Output("FAILURE OR OK?")

Write-Output("TYPE 1 FOR FAILURE")

Write-Output("TYPE 2 FOR OK")



$status = Read-host "SELECT 1 OR 2 "


Write-Output("---","the option to be performed is: ", $status, "---")

$headers=@{}

$headers.Add("content-type", "application/json")

$response = Invoke-WebRequest -Uri 'https://apis.elven.works/external/auth/v1/client/<Your Company URL>' `

-Method POST `

-Headers $headers `

-ContentType 'application/json' `

-Body '{"client_id": "<YOUR INFORMATION HERE>","client_secret": "<YOUR INFORMATION HERE>"}'



$StatusCode = $Response.StatusCode 

Write-Output "Get Token 1P - código resposta: $StatusCode" 

$token = ($response.Content | ConvertFrom-Json).access_token

$Date = Get-Date

$headers.Add("authorization", "Bearer $token")

$invoke_headers =@{

authorization = "Bearer $token"

}

$invoke_headers.Add("content-type", "application/json")


if($status -eq 2)

{

Write-Output("HITS")

$HITS = Invoke-WebRequest -Uri 'https://apis.elven.works/external/monitoring/v1/hits' `

-Method POST `

-Headers $invoke_headers `

-ContentType 'application/json' `

-Body '{"latency": 100000, "service": <YOUR SERVICE ID HERE>, "organization": "<YOUR ORGANIZATION ID HERE>"}'

Write-Output("$HITS")

}

if($status -eq 1)

{

Write-Output("FAILURE")

$FAILURE = Invoke-WebRequest -Uri 'https://apis.elven.works/external/monitoring/v1/failures' `

-Method POST `

-Headers $invoke_headers `

-ContentType 'application/json' `

-Body '{"issue": "ERROR MESSAGE", "service": <YOUR SERVICE ID HERE>, "organization": "<YOUR ORGANIZATION ID HERE>"}'

Write-Output($FAILURE)

}
				
			

Incidents represent confirmed situations that affect the normal operation of systems or services, requiring response and mitigation. While alerts are precursors that signal possible problems, incidents already confirm the occurrence of real problems and require immediate action to minimize impacts and restore operational normality.

In our Incident Center, you can check all essential information about incidents generated or received by One Platform. You can configure to generate incidents through:

  • Integrations (to request integrations, contact Elven)
  • Create a manual incident
  • Through monitoring on One Platform


You can filter the listed incidents according to:

  • Source
  • Incident Status
  • Severity
  • Period

 

You can also add filters through the url, the accepted parameters are as follows:

  • Source

    • integrations
    • resources
  • Status

    • alarmed
    • acknowledged
    • resolved

  • Severity

    • sev1 ou sev-1-critical
    • sev2 ou sev-2-high
    • sev3 ou sev-3-moderate
    • sev4 ou sev-4-low
    • sev5 ou sev-5-informational
    • not-classified 
  • Period

    • 1
    • 7
    • 30
    • 12

url example: https://1p.elven.works/incidents?source=resources&status=resolved&severity=not-classified&period=12

Note: When you do not pass the parameter, the value “all” will be considered.

Deleting an incident from the incident center

To delete an incident, simply click on the three dots to the right of it and click on “Delete Incident” (incidents originating through manual incident or external integration can be deleted)



Alerts are resources that precede the opening of an incident, which helps the user to act before something more critical happens to the health of their organization. In our Alerts Center, you can check essential information about the alerts generated by One Platform. A solution designed to reduce risks and increase the reliability of digital products.

In principle, it is only possible to generate an alert on the platform via external integration. To carry out external integrations, contact ElvenWorks and one of our experts will assist you.



 You can filter the listed incidents according to:

  • Status
  • Severity
  • Period



You can also add filters through the url, the accepted parameters are as follows:

  • Status

    • alarmed
    • acknowledged
    • resolved
  • Severity

    • sev1 ou sev-1-critical
    • sev2 ou sev-2-high
    • sev3 ou sev-3-moderate
    • sev4 ou sev-4-low
    • sev5 ou sev-5-informational
    • not-classified 
  • Period

    • 1
    • 7
    • 30
    • 12

url example: https://1p.elven.works/alert-center?status=alarmed&severity=sev1&period=30

Note: When you do not pass the parameter, the value “all” will be considered.

Cassandra is a highly scalable and highly available distributed database designed to handle large volumes of data distributed across multiple servers. Developed by Facebook and later released as open source software, Cassandra follows the columnar NoSQL database model. It provides high fault tolerance and no single points of failure, allowing data to be distributed across multiple machines and replicated to ensure redundancy and availability. Cassandra is optimized for fast writes and efficient read queries on large data sets, making it suitable for use cases that require high scalability, such as big data analytics applications, IoT, and real-time applications. With its distributed architecture and schema flexibility, Cassandra is a popular choice for companies that need to deal with data on a global, ever-growing scale.

How to monitor Cassandra on One Platform

1 – In the side menu, click on Services Hub


2 – In the Database category, click on the Cassandra card


3 – You will be directed to the Cassandra configuration page, fill in the fields


4 – If you want, you can configure automatic incident opening. In the Open automatic incident section, fill in the fields:

  • Severity -> Choose between “SEV-1 – Critical”, “SEV-2 – High”, “SEV-3 – Moderate”, “SEV-4 – Low”, “SEV-5 – Informational” or “Not Classified”;
  • Check Interval in seconds -> This is the interval at which checking will take place (this interval cannot be less than the number of failures x the Interval configured in the monitoring form;
  • Failures to open automatic incident -> It is the number of failures necessary to open the automatic incident;
  • Check Interval in seconds -> This is the interval in which checking will take place (this interval cannot be less than the number of hits x the Interval configured in the monitoring form;
  • Hits to close automatic incident -> It is the number of hits needed to close the automatic incident;
  • Responders -> These are the teams that will be notified if there are incidents in this monitoring, and you can add one or multiple teams;

If necessary, you can create a team by clicking + RESPONDER, you will be directed to the form

to create the team, then click on the button  for the new team to appear in the list

***Don’t forget to activate the Enable to set up automatic incidents opening toggle to save the automatic incident opening settings


5 – Click on CREATE MONITORING 

Cassandra is a highly scalable and highly available distributed
database designed to handle large volumes of data distributed across
multiple servers. Developed by Facebook and later released as
open-source software, Cassandra follows the columnar NoSQL database
model. It provides high fault tolerance and lacks single points of
failure, allowing data to be distributed across multiple machines and
replicated to ensure redundancy and availability. Cassandra is optimized
for fast writes and efficient read queries on large datasets, making it
suitable for use cases that require high scalability, such as big data
analytics, IoT, and real-time applications. With its distributed
architecture and schema flexibility, Cassandra is a popular choice for
companies that need to handle data on a global and ever-growing scale.

How to Monitor Cassandra on the One Platform

To set up monitoring for Cassandra on the platform, follow these steps:

  1. Go to the product application where you want to add Cassandra as a dependency in the platform.

  2. Click on the “Products” menu and select the desired product card.

  3. Then, click on the name of the specific application where you want to configure Cassandra monitoring.

  4. Look for the section called “External Dependencies,” usually located just below the latency graph of the application.

  5. To add an already registered dependency, type the name of the
    dependency in the search field and select it when it appears in the
    list.

  6. If Cassandra is not yet registered as a dependency, click on the green button with a plus (+) symbol to add a new dependency.


Click “Add” and a modal will appear allowing you to name the database and select the Environment. In the “Check type” field, choose the option “DB,” and in the “Method” field, select “Cassandra.” After selecting the method, a field for the Healthcheck URL will appear.


Below is an example of string for Cassandra:

ex: HOST:PORT@USER/PASSWORD

Note: For security reasons, it is not permitted to enter an IP in the healthcheck field. To monitor an IP, you need to enter it in a secret and use it in healthcheck

Azure Service Bus is an asynchronous and distributed messaging service offered by Microsoft Azure. It provides publish and subscribe capabilities, queues, and commit messages to facilitate communication between distributed applications and components. Service Bus allows producers to send messages to topics or place messages on queues, while consumers subscribe to topics or retrieve messages from queues for processing. It ensures reliable delivery of messages even in case of temporary failures and offers advanced features such as message filtering, rate control, and expiration time-based message queuing. Additionally, Azure Service Bus integrates seamlessly with other Azure services such as Azure Functions, Logic Apps, and Azure Functions. It is widely used in distributed architectures, microservices, real-time applications, event systems, and application integration scenarios, providing a reliable and scalable solution for exchanging messages between components of a system in the Azure cloud.

How to monitor Service Bus on One Platform

1 – In the side menu, click on Services Hub


2 – In the Queue category, click on the  Service Bus (Azure) card


3 – You will be directed to the Service Bus (Azure) configuration form, fill in the fields


4 – If you want, you can configure automatic incident opening. In the Open automatic incident section, fill in the fields:

  • Severity -> Choose between “SEV-1 – Critical”, “SEV-2 – High”, “SEV-3 – Moderate”, “SEV-4 – Low”, “SEV-5 – Informational” or “Not Classified”;
  • Check Interval in seconds -> This is the interval at which checking will take place (this interval cannot be less than the number of failures x the Interval configured in the monitoring form;
  • Failures to open automatic incident -> It is the number of failures necessary to open the automatic incident;
  • Check Interval in seconds -> This is the interval in which checking will take place (this interval cannot be less than the number of hits x the Interval configured in the monitoring form;
  • Hits to close automatic incident -> It is the number of hits needed to close the automatic incident;
  • Responders -> These are the teams that will be notified if there are incidents in this monitoring, and you can add one or multiple teams;

If necessary, you can create a team by clicking + RESPONDER, you will be directed to the form

to create the team, then click on the button  for the new team to appear in the list

***Don’t forget to activate the Enable to set up automatic incidents opening toggle to save the automatic incident opening settings


5 – Click on CREATE MONITORING 

SQS (Simple Queue Service) is a fully managed message queuing service provided by Amazon Web Services (AWS). It allows developers to asynchronously send, store, and receive messages between distributed application components. SQS is highly scalable and fault tolerant, ensuring that messages are processed reliably and in an orderly manner. Producers send messages to queues and consumers retrieve them for processing. SQS offers two types of queues: Standard Queue and FIFO Queue, which differ in their message delivery and ordering capabilities. The SQS service is flexible and can be easily integrated with other AWS services such as EC2, Lambda, and SNS. It is particularly used in distributed scenarios, microservices, batch processing, email notifications, and other use cases where asynchronous and reliable communication between components is required. With the fully managed nature of the service, developers can focus on business logic without worrying about the underlying message queue infrastructure.

How to monitor SQS on One Platform

1 – In the side menu, click on Services Hub


2 – In the Queue category, click on the  SQS(AWS) card


3 – You will be directed to the SQS configuration form, fill in the fields


4 – If you want, you can configure automatic incident opening. In the Open automatic incident section, fill in the fields:

  • Severity -> Choose between “SEV-1 – Critical”, “SEV-2 – High”, “SEV-3 – Moderate”, “SEV-4 – Low”, “SEV-5 – Informational” or “Not Classified”;
  • Check Interval in seconds -> This is the interval at which checking will take place (this interval cannot be less than the number of failures x the Interval configured in the monitoring form;
  • Failures to open automatic incident -> It is the number of failures necessary to open the automatic incident;
  • Check Interval in seconds -> This is the interval in which checking will take place (this interval cannot be less than the number of hits x the Interval configured in the monitoring form;
  • Hits to close automatic incident -> It is the number of hits needed to close the automatic incident;
  • Responders -> These are the teams that will be notified if there are incidents in this monitoring, and you can add one or multiple teams;

If necessary, you can create a team by clicking + RESPONDER, you will be directed to the form

to create the team, then click on the button  for the new team to appear in the list

***Don’t forget to activate the Enable to set up automatic incidents opening toggle to save the automatic incident opening settings


5 – Click on CREATE MONITORING 

Internal monitoring, carried out by the ElvenWorks agent, installed in your infrastructure to check internal and private resources. To choose this type of monitoring, click on Product in the platform’s side menu and click on the card “An internal application monitored by our agent”.


Monitoring that takes place in a hybrid way, in an external application, but with installation of the ElvenWorks agent. Our servers geographically distributed networks will monitor a public application, with internal dependencies. An example is monitoring a public website with the database being monitored internally. To choose For this type of monitoring, click on Product in the platform’s side menu and click on the card “An external application with an ElvenWorks agent”.


You can have multiple teams in your account and add your team members to your platform account can facilitate collaboration. You can also add a contact to multiple teams. To have your team onboard, follow the steps below.

Select the “Teams” area in the left side menu and choose a team to send the invitation to team members. Enter the name of the email of your team’s user and choose your role. Click “Add” to add. 

Scroll to Top