The same way the monitoring definition changes across contexts, its components follow the same predicament. Depending on how broad you want to be, we can find some or all of these components in the following topics:

• Metrics: This exposes a certain system resource, application action, or business characteristic as a specific point in time value. This information is obtained in an aggregated form; for example, you can find out how many requests per second were served but not the exact time for a specific request, and without context, you won't know the ID of the requests.
• Logging: Containing much more data than a metric, this manifests itself as an event from a system or application, containing all the information that's produced by such an event. This information is not aggregated and has the full context.
• Tracing: This is a special case of logging where a request is given a unique identifier so that it can be tracked during its entire life cycle across every system. Due to the increase of the dataset with the number of requests, it is a good idea to use samples instead of tracking all requests.
• Alerting: This is the continuous threshold validation of metrics or logs, and fires an action or notification in the case of a transgression of the said threshold.
• Visualization: This is a graphical representation of metrics, logs, or traces.

Recently, the term monitoring has been overtaken by a superset called observability, which is regarded as the evolution of monitoring, or a different wrapping to spring a hype and revive the concept (the same way it happened with DevOps). From where it stands, observability does indeed include all the components we described here.

Throughout this book, our monitoring definition incorporates metrics, alerting, and visualization.