c57e68a0cd
Automated changes by
[create-pull-request](https://github.com/peter-evans/create-pull-request)
GitHub action
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Signed-off-by: f41gh7 <nik@victoriametrics.com>
(cherry picked from commit 015f0b0424)
3.9 KiB
| weight | title | menu | aliases | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12 | VMServiceScrape |
|
|
The VMServiceScrape CRD allows to define a dynamic set of services for monitoring. Services
and scraping configurations can be matched via label selections. This allows an organization to introduce conventions
for how metrics should be exposed. Following these conventions new services will be discovered automatically without
need to reconfigure.
VMServiceScrape object generates part of VMAgent configuration with
kubernetes service discovery targets by corresponding Service.
It has various options for scraping configuration of target (with basic auth,tls access, by specific port name etc.).
Monitoring configuration based on discoveryRole setting. By default, endpoints is used to get objects from kubernetes api.
It's also possible to use discoveryRole: service or discoveryRole: endpointslices.
Endpoints objects are essentially lists of IP addresses.
Typically, Endpoints objects are populated by Service object. Service object discovers Pods by a label
selector and adds those to the Endpoints object.
A Service may expose one or more service ports backed by a list of one or multiple endpoints pointing to
specific Pods. The same reflected in the respective Endpoints object as well.
The VMServiceScrape object discovers Endpoints objects and configures VMAgent to monitor Pods.
The Endpoints section of the VMServiceScrapeSpec is used to configure which Endpoints ports should be scraped.
For advanced use cases, one may want to monitor ports of backing Pods, which are not a part of the service endpoints.
Therefore, when specifying an endpoint in the endpoints section, they are strictly used.
Note: endpoints (lowercase) is the field in the VMServiceScrape CRD, while Endpoints (capitalized) is the Kubernetes object kind.
Both VMServiceScrape and discovered targets may belong to any namespace. It is important for cross-namespace monitoring
use cases, e.g. for meta-monitoring. Using the serviceScrapeSelector of the VMAgentSpec
one can restrict the namespaces from which VMServiceScrapes are selected from by the respective VMAgent server.
Using the namespaceSelector of the VMServiceScrape one can restrict the namespaces from which Endpoints can be
discovered from. To discover targets in all namespaces the namespaceSelector has to be empty:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMServiceScrape
metadata:
name: example-service-scrape
spec:
namespaceSelector: {}
# ...
More information about selectors you can find in this doc.
Specification
You can see the full actual specification of the VMServiceScrape resource in
the API docs -> VMServiceScrape.
Also, you can check out the examples section.
Migration from Prometheus
The VMServiceScrape CRD from VictoriaMetrics Operator is a drop-in replacement
for the Prometheus ServiceMonitor from prometheus-operator.
More details about migration from prometheus-operator you can read in this doc.
Examples
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMServiceScrape
metadata:
name: example-app
labels:
team: frontend
spec:
selector:
matchLabels:
app: example-app
endpoints:
- port: web