Monitoring is the most basic component in their reliability pyramid and enables incident response and postmortems.

"Monitoring tells you whether a systems is working, observability lets you ask why it isn't working."

Observability means assembling all fragments from logs, monitoring tools and

organize them in such a way which gives actionable knowledge of the whole

enviroment, thus creating an insight.

Taken from Article, Observability Working Architecture and Benifits

Once upon a time there was “Monitoring”

Observability is a superset of monitoring. It provides not only high-level overviews of the system’s health but also highly granular insights into the implicit failure modes of the system.

In addition, an observable system furnishes ample context about its inner workings, unlocking the ability to uncover deeper, systemic issues.

Monitoring, on the other hand, is best suited to report the overall health of systems and to derive alerts.

Telemetry is the collection of measurements or other data at remote points and their automatic transmission to receiving equipment for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure".

Four essential telemetry data types

1. Metrics
2. Events
3. Logs
4. Traces

Metrics represent the data in your system, monitoring is the process of collecting, aggregating, and analyzing those values to improve awareness of your components' characteristics and behavior.

Metrics capture a value pertaining to your systems at a specific point in time — for example, the number of users currently logged in to a web application. Therefore, metrics are usually collected once per second, one per minute, or at another regular interval to monitor a system over time.

There are two important categories of metrics in our framework: work metrics and resource metrics.

Work metrics indicate the top-level health of your system by measuring its useful output. It’s often helpful to break them down into four subtypes:

Example of
Work Metrics

A server’s resources include such physical components as CPU, memory, disks, and network interfaces. Including a database or a geolocation microservice, can also be considered a resource if another system requires that component to produce work. For each resource in your system, try to collect metrics that cover four key areas:

1. utilization is the percentage of time that the resource is busy, or the percentage of the resource’s capacity that is in use.
2. saturation is a measure of the amount of requested work that the resource cannot yet service, often queued.
3. errors represent internal errors that may not be observable in the work the resource produces.
4. availability represents the percentage of time that the resource responded to requests. This metric is only well-defined for resources that can be actively and regularly checked for availability.

In addition to metrics, which are collected more or less continuously, some monitoring systems can also capture events: discrete, infrequent occurrences that can provide crucial context for understanding what changed in your system’s behavior. Some examples:

• Changes: Internal code releases, builds, and build failures
• Alerts: Internally generated alerts or third-party notifications
• Scaling events: Adding or subtracting hosts

An event usually carries enough information that it can be interpreted on its own. Events capture what happened, at a point in time, with optional additional information. 

Service Oriented Architecture
SOA
Architecture Diagram

Too many
Micro services!!!!

Datadog Course

2. Datadog Infrastructure Monitoring