Adding a New Scraper
This guide walks you through the process of adding a new scraper type.
Implementing a Scaler
- Add your new scraping type to the
- Describe the resource for which you're scraping metrics by creating
<New-Type>ResourceDefinitionand inherit from
Promitor.Core.Scraping.Configuration.Model.Metrics.AzureResourceDefinition- this class should go in
- Describe the resource configuration for which you're scraping metrics by creating
<New-Type>ResourceV1and inherit from
Promitor.Core.Scraping.Configuration.Serialization.v1.Model.AzureResourceDefinitionV1- this class should go in
- Create a new Deserializer in
.\src\Promitor.Core.Scraping\Configuration\Serialization\v1\Providers. This must inherit from
Promitor.Core.Scraping.Configuration.v1.Core.AzureResourceDeserializerFactoryto handle your new resource type by returning a new instance of the Deserializer you created in the previous step.
- Update the
Promitor.Core.Scraping.Configuration.Serialization.v1.Mapping.V1MappingProfileso that it:
- Is able to map your new resource type by mapping the
- Annotate how to map it with
- Provide a unit test in
.\src\Promitor.Tests.Unit\Serialization\v1\Providersthat tests the deserialization based on our sample. Your test class must inherit from
ResourceDeserializerTestto ensure the inherited functionality is tested.
Going forward in this guide,
TResourceDefinition will refer to your newly created
For every scraper type we provide validation for the configuration so that Promitor fails to start up.
This requires the following steps:
- Create a new validator that implements
IMetricValidator. This validator should reside in
.\src\Promitor.Agents.Scraper\Validation\MetricDefinitions\ResourceTypes. You can look at the contents of
ServiceBusQueueMetricValidatorfor an idea of the validation inputs, steps, and outputs typical of validator implementation.
- Add construction and usage of this validator to
.\src\Promitor.Agents.Scraper\Validation\Factories\MetricValidatorFactory.csfor the ResourceType you created in step #1 above.
- Provide a unit test for every validation rule that was added in
We'll add a new scraper that pulls the metrics from Azure Monitor:
- Implement a scraper, that inherits from
AzureMonitorScraper<TResourceDefinition>, which will specify what resource to scrape with Azure Monitor.
- Hook your new scraper in our
MetricScraperFactorywhich determines what scraper to use for the passed configuration.
We'll add dynamic resource discovery support by using Azure Resource Graph:
- Implement a new discovery query that create an Azure Resource Graph query.It should inherits from
ResourceDiscoveryQueryand be located in
- Support the new resource type in
- Add discovery support badge in scraper documentation page -
![Resource Discovery Support Badge](https://img.shields.io/badge/Support%20for%20Resource%20Discovery-Yes-green.svg)
- Add scraper to supported scrapers on resource discovery configuration documentation page
docs/configuration/v2.x/resource-discovery.mdin alphabetical order.
Features are great to have but without clear & well-written documentation they are somewhat useless.
Please provide documentation on the following:
- What Azure service it supports and how to use it.
- What fields need to be configured and what they are for.
- An example configuration.
This should be provided in a new file under
docs\configuration\v2.x\metrics and be listed
under the supported providers on
docs/configuration/v2.x/metrics/index.md in alphabetical order.
See It In Action
Now that you are done, make sure you run Promitor locally so verify that it generates the correct metrics!
When opening the pull request (PR), feel free to copy the generated Prometheus metrics for review.
Learn how to run it in our development guide.