doc: Provide capability to define metric window starting point to que…

…ry Azure Monitor (#32)

docs/scraping/runtime-configuration.md

@@ -42,6 +42,13 @@ metricSinks:
     metricPrefix: promitor. # Optional. Default: None
 metricsConfiguration:
   absolutePath: /config/metrics-declaration.yaml # Optional. Default: /config/metrics-declaration.yaml
+azureMonitor:
+  logging:
+    informationLevel: Basic # Optional. Default: Basic
+    isEnabled: false # Optional. Default: false
+  integration:
+    history:
+      startingFromInHours: 24 # Optional. Default: 12
 telemetry:
   applicationInsights:
     instrumentationKey: ABC # Optional. Note: Required to be specified when turned on
@@ -345,6 +352,8 @@ The behavior of this can be configured to fit your needs:
  options are `Basic`, `Headers`, `Body` & `BodyAndHeaders`. (Default: `Basic`)
 - `azureMonitor.logging.isEnabled` - Defines whether or not information concerning the integration with Azure Monitor
  API. (Default: `false`)
+- `azureMonitor.integration.history.startingFromInHours` - Defines the amount of hours Promitor will use to define the starting point of the time window used for metric queries.
+  - As an example, the default is 12 hours which means Promitor will fetch all metrics between now - 12 hours and now to find a matching metric. Typically this window can be very small but Promitor provides a margin by default to prevent problems for long aggregation periods. (Default: `12`)
 
 Example:
 
@@ -353,6 +362,9 @@ azureMonitor:
   logging:
     informationLevel: Basic # Optional. Default: Basic
     isEnabled: false # Optional. Default: false
+  integration:
+    history:
+      startingFromInHours: 24 # Optional. Default: 12
 ```
 
 _Note: All telemetry is emitted as `trace` so you have to make sure `telemetry` is configured correctly._