## Overview Instrumentation is key to better understand how our services are performed. According to the best practice, we should instrument every library, subsystem and service to retrieve metrics in order to understand how it is performing. ## Our goal Instrumentation should be an integral part of the code. We should strive to make instrumentation as seamlessly as possible ## How We should add the ability to instrument and retrieve application metrics throughout the entire application lifecycle stages * **While writing code** automatically add the code block for the client library (Java, Go, .Net, etc..) and the metric type (Gauge, Counter or Histogram). * **At run time** automatically identify which frameworks and libraries are in use within the application and instrument those libraries to capture tracing instrumentation.(aka auto-instrumentation) * **When deploying applications into production** automatically detect workload and deploy the right [exporters](https://prometheus.io/docs/instrumenting/exporters/) into it * **Setting thresholds** visually with a metric's historical context to ensure there is an immediate sense of the impact of the threshold change * **Source controlled** SLO and threshold definition to ensure your entire team can collaborate on changes and they can be tested prior to adjusting ## User Journeys The following are high-level, visionary journeys we want to enable in GitLab. Each step in these journeys could be a detailed workflow. Additionally, these journeys are ever evolving as we learn more about our users and identify new opportunities. [Alerting Workflow](https://app.mural.co/t/gitlab2474/m/gitlab2474/1570091486919/e158f2708a5615fec6b7eb1f71743a02c6c89a9d)