Configuring an alarm: example 1

PreviousConfigured alarms NextConfiguring an alarm: example 2

Last updated 3 years ago

Was this helpful?

Configuring an alarm: example 1

Looking at the alarms defined in the system, we want to configure an alarm that reports, as soon as possible, of any ingestion job of an excessive size, in any of the preservation areas, and whoever it is that creates it.

So we will be ready to monitor the system’s performance and check with the user that generated the job that it is really an intended job, as well as to consult on similar jobs to be launched.

As there is no preparameterized and easy to use alarm that references ingestion jobs in their starting steps, we will configure an instance of the alarm New state of ingestion job.

The parameter values we will use are:

General:
1. Criticality = Urgency.
2. Importance = High.
3. Check period: every minute. This alarm process does not affect system performance (no heavy duty to perform).
4. User comment: an indication of the kind ‘Early detection of big size ingestions’.
Alarm (these parameters are specific to this alarm):
1. Achieved state: Created.
2. Preservation area. We do not select anything, so the parameter will not apply and will refer to all areas.
3. User. We do not select any, so it will refer to ingestion jobs created by any user.
4. Group. We do not select any, so it will refer to ingestion jobs created by a user belonging to any kind of user groups.
5. Minimum size. The size we want to check for: for example, 20.000 Mbytes (almost 20 GB).
Notification:
1. Message building rule. We do not want to wait for the detection of several objects to get the notification (we want early notice), so this parameter does not mean much in this case. Still though, using the Add the notification text under the new execution is recommended.
2. Maximum number of messages without sending e-mail. We set to 1. So, as soon as there is a notification, it will be sent by e-mail. That is, a second text to add is never waited for.
3. Maximum time without sending e-mail. As if there is no notification there is nothing to be sent, and if there is one notification it will be sent immediately, this parameter has no use in this particular case.
4. Receiver (user). Whoever we want.
5. Receiver (group). Whichever we want; it would be reasonable to set for system administrators, if we are monitoring because of the space used, or for preservation administrators, if we are monitoring for an object inadequately formed for preservation.
6. Can deactivate notification. Checked, as there is no sense in this kind of notifications to be persistent.
7. E-mail sending deactivates notification. Not checked, so we can see the notification active in the panel until we acknowledge manually.

With this configuration, it will be one minute at the most between the creation of an ingestion job with objects of more than 20Gbytes and the sending of an e-mail notifying the fact.

PreviousConfigured alarms NextConfiguring an alarm: example 2

Last updated 3 years ago

Was this helpful?

So we will be ready to monitor the system’s performance and check with the user that generated the job that it is really an intended job, as well as to consult on similar jobs to be launched.

As there is no preparameterized and easy to use alarm that references ingestion jobs in their starting steps, we will configure an instance of the alarm New state of ingestion job.

The parameter values we will use are:

General:
1. Criticality = Urgency.
2. Importance = High.
3. Check period: every minute. This alarm process does not affect system performance (no heavy duty to perform).
4. User comment: an indication of the kind ‘Early detection of big size ingestions’.
Alarm (these parameters are specific to this alarm):
1. Achieved state: Created.
2. Preservation area. We do not select anything, so the parameter will not apply and will refer to all areas.
3. User. We do not select any, so it will refer to ingestion jobs created by any user.
4. Group. We do not select any, so it will refer to ingestion jobs created by a user belonging to any kind of user groups.
5. Minimum size. The size we want to check for: for example, 20.000 Mbytes (almost 20 GB).
Notification:
1. Message building rule. We do not want to wait for the detection of several objects to get the notification (we want early notice), so this parameter does not mean much in this case. Still though, using the Add the notification text under the new execution is recommended.
2. Maximum number of messages without sending e-mail. We set to 1. So, as soon as there is a notification, it will be sent by e-mail. That is, a second text to add is never waited for.
3. Maximum time without sending e-mail. As if there is no notification there is nothing to be sent, and if there is one notification it will be sent immediately, this parameter has no use in this particular case.
4. Receiver (user). Whoever we want.
5. Receiver (group). Whichever we want; it would be reasonable to set for system administrators, if we are monitoring because of the space used, or for preservation administrators, if we are monitoring for an object inadequately formed for preservation.
6. Can deactivate notification. Checked, as there is no sense in this kind of notifications to be persistent.
7. E-mail sending deactivates notification. Not checked, so we can see the notification active in the panel until we acknowledge manually.

With this configuration, it will be one minute at the most between the creation of an ingestion job with objects of more than 20Gbytes and the sending of an e-mail notifying the fact.