• Introduction
• Status Page : landing page
• How is the status computed ?

Introduction

Before we start some definitions about the services, service types and service endpoints.
• From the ARGO monitoring service perspective, a monitored infrastructure is composed of a group of services.
• Services are composed of service instances of a specific Service Type, which are called Service Endpoints.
• A Service Type is a group of metrics that are checking a specific service from the monitoring perspective.
• Each Service Type can have a defined set of metrics, which are explicit tests that we run in order to assess the status of a Service Endpoint.

Status Page : landing page

• Above the timelines there is an arrow that can help you navigate through the days (divvious or next when available).
• You may drill down to the services page and get more information about the services endpoints and finally about the metrics

How is the status computed?

• The ARGO Analytics Engine expects to receive a stream of metric results produced by a monitoring engine.
• A metric result is the output of a specific test that was run at a specific time against a specific service endpoint.
• A metric result includes at least:

• a timestamp showing when the given monitoring probe was executed
• the name of the service type (e.g. HTTPS Web Server)
• the name of the hostname on which the service is running (e.g. www.example.com)
• the name of the metric that was tested (e.g. TCP_CHECK)
• the status result that was produced by the monitoring probe (e.g. OK)

 {
    "timestamp": "2019-05-02T10:53:38Z",
    "metric": "org.web.check-tcp",
    "service_type": "HTTPS Web Server",
    "hostname": "www.example.com",
    "status": "OK"
}

• A OK state that means that the operation of the service endpoint / service / service group is normal
• A WARNING state is used for situations when service is still functional, but it is in a non-optimal state. This state is most often used in combination with thresholds, e.g. if response time is more than X or certificate lifetime expires in less than X days. This state changes the state of the / service / service group based on the profiles defined.
• A CRITICAL state is used for situations when service is not functioning properly or at all. This means that the service is not responding correctly to the checks metrics that are executed. This state changes the state of the / service / service group based on the profiles defined.
• A DOWNTIME state, that means that the service endpoint / service / service group has declared downtime for a period.

• A MISSING state, which is used in order to fill the timelines when a metric isn’t divsent in the consumer data for a period of time
• An UNKNOWN state, which is used in order fill the timelines when a re-computation exclusion is applied

• Introduction
• Set a downtime period
• Update a downtime
• Delete a downtime
• View downtime Calendar

Introduction

• One of the most important features of the registry is the Downtime Calendar, through which users can inform others that a service will stop being active for a certain period of time.
• A downtime is a period of time for which a service is declared to be inoperable. Downtimes may be scheduled (e.g. for software/hardware upgrades), or unscheduled (e.g. power outages).
• All the features described in this document are available here : SDC GOCDB
• All downtimes declared in GOC DB will be reflected into the ARGO system .

Set a downtime period

• The downtime classification (Scheduled or unscheduled)
• The severity of the downtime
• The date at which the downtime was added
• The start and end of the downtime period
• A description of the downtime
• The entities affected by the downtime

• Scheduled: planned and agreed in advance
• Unscheduled: planned or unplanned, usually triggered by an unexpected failure or at a short term notice

• All dates have to be entered in UTC.
• A downtime can be retrospectively added if its start-date is less than 48h in the past (giving a 2 day window to add).
• downtime classification (scheduled/unscheduled) is determined automatically

• Severity: When declaring a downtime, you will be presented the choice of a "severity", which can be either WARNING or OUTAGE. Please consider the following definitions:
  • Outage : means the resource is considered as unavailable. Such downtimes will be considered as "IN MAINTENANCE" by monitoring and availability calculation tools.
  • Warning : means the resource is considered available, but the quality of service might be degraded. Such downtimes generate notifications, but are not taken into account by monitoring and availability calculation tools.
• Description: A description about the downtime.
  
  
• Starts on
  • Day: The day it starts.
  • Time: The exact start time please add a correct timezone
• Ends on
  • Day: The day it ends.
  • Time: The exact end time please add a correct timezone
• Select Affected Site: Select the site that is going to be affected.
• Select Affected Services + Endpoints: Which services will be affected.

Update a downtime

Delete a downtime

View downtime Calendar

• Introduction
• Last status checks
• Downtimes

Introduction

This page is a synoptic view for your monitoring data and a given report (ex. Critical.)

The main information consists of
• the description of the topology - structure (project, sites,) and list of the related entries
• the results of availabilities/reliabilities for the last 30 days
• The last status check via a donut chart . (more information below)
• The last status changes.(more information below)
• The downtimes affecting the the services (more information below)

Last status checks

Donut Chart

The doughnut chart shows the last status checks. Pie and doughnut charts are probably the most commonly used charts.

They are divided into segments, the arc of each segment shows the proportional value of each piece of data. Here the segment is the different results of checks

You may see the number of Critical, Missing, Ok, Unknown, and Warning Checks.

>

Last statuses Table

From this table you may see the 500 last status changes with the distribution and the details of these changes.

This table has the functionalities of searching and sorting the data in order to find the check you are looking for.

At the bottom of the table pagination is enabled to help you navigate through the results. Βy clicking on the lens icon you can see more information about the status.

Downtimes

From here you may see the downtimes affecting the sites/services. This table has the functionalities of searching and sorting the data in order to find the check you are looking for.

At the bottom of the table pagination is enabled to help you navigate through the results. Βy clicking on the lens icon you can see more information about the downtime.

• Introduction
• What is a custom report ?
• Results

Introduction

What is a custom report ?

A Custom report is a report about a service in a selected period of time.

In order to create your report you must specify at least:
• Entity: The entity you want to get the report about
• Report Type: you can select the type report a) Availability/Reliability - Daily values, b) Availability/Reliability - Monthly values, c) Status
• Timeline: The period of time for the report like Today, Yesterday, Last 7 Days, Last 30 Days, This Month, Last Month, Last 3 Months, Last 6 Months or a Custom Range.

Results

According to the type of report you select the results are shown in the following images.

Availability/Reliability - Daily values

Availability/Reliability - Monthly values

Status report

Core Services

1. The Infrastructure Service Group

2. The Homepage Service Group

3. The Downstream Service Group

Other Services