{"id":19096507,"url":"https://github.com/sapcc/vrops-exporter","last_synced_at":"2025-04-15T17:24:44.045Z","repository":{"id":37392883,"uuid":"215293474","full_name":"sapcc/vrops-exporter","owner":"sapcc","description":"Prometheus exporter running python to get metrics out of VMware vRealize Operations","archived":false,"fork":false,"pushed_at":"2025-04-09T04:28:29.000Z","size":1506,"stargazers_count":25,"open_issues_count":16,"forks_count":17,"subscribers_count":52,"default_branch":"master","last_synced_at":"2025-04-09T05:26:22.541Z","etag":null,"topics":["metrics","prometheus-exporter","python3"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sapcc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-10-15T12:29:25.000Z","updated_at":"2025-03-13T08:12:59.000Z","dependencies_parsed_at":"2024-02-04T00:24:25.415Z","dependency_job_id":"d880e3a0-2200-43d1-9039-ca76424d769b","html_url":"https://github.com/sapcc/vrops-exporter","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sapcc%2Fvrops-exporter","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sapcc%2Fvrops-exporter/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sapcc%2Fvrops-exporter/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sapcc%2Fvrops-exporter/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sapcc","download_url":"https://codeload.github.com/sapcc/vrops-exporter/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249117208,"owners_count":21215350,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["metrics","prometheus-exporter","python3"],"created_at":"2024-11-09T03:36:55.921Z","updated_at":"2025-04-15T17:24:44.014Z","avatar_url":"https://github.com/sapcc.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"![Python application](https://github.com/sapcc/vrops-exporter/actions/workflows/pythonapp.yml/badge.svg)\n[![Coverage Status](https://coveralls.io/repos/github/sapcc/vrops-exporter/badge.svg?branch=master)](https://coveralls.io/github/sapcc/vrops-exporter?branch=master)\n\n# vrops-exporter\nPrometheus exporter for VMware vRealize Operations Manager\n\n###### Tested and compatible with vROps 6.5 up to vROps v8.6.2\n\n### Table of Contents\n\n[Design](#design)\n\n[Supported adapters and resourcekinds](#supported-adapters-and-resourcekinds)\n\n[Running the software](#running-the-software)\n\n[Running in Kubernetes](#running-in-kubernetes)\n\n[Test](#test)\n\n## Design\n\nThe exporter is divided in two main components, [inventory](#inventory) and [exporter](#exporter). \nThe inventory is providing the resource-uuids (unique unit identifier) from vROps via a REST interface to the exporter\n\n#### inventory\n\nThe inventory collects all supported resourcekinds in their parent-child relation, and makes them available at an internal API. \nThe resourcekinds are updated by a continuous cycle that can be configured with `--sleep`. The inventory preserves data through iterations. \nThe last two iterations for these cycles are always provided via the endpoints and in order to know which iteration to fetch, \nlatest iteration needs to be queried first.\n\nTo have more control over the resources to be collected, they can be filtered by _resourcestatus_, _resourcehealth_ and _resourcestate_ in [inventory-config](tests/inventory_config.yaml).\n\n###### inventory endpoints\n```shell\nGET\n\n/target                                           # vrops FQDN\n/\u003ctarget\u003e/\u003cresourcekind\u003e/\u003cint:iteration\u003e          # path for each resourcekind\n/alertdefinitions/                                # vrops integrated alertdefinitions\n/iteration                                        # current inventory iteration\n/amount_resources                                 # amount of resources for each resourcekind\n/collection_times                                 # measured time for a inventory run per vrops\n/api_response_codes                               # HTTP response codes per resourcekind GET request\n/target_tokens                                    # dict with vrops: auth token\n```\n#### exporter\n\nThe second component are the collectors that exist for each resourcekind as well as for metrics, properties and alerts. \nEach collector performs only one task - one resourcekind and one type from the three different values. First, the resourcekinds in question are \nqueried at the inventory's internal API. In the second step, the values, properties or alarms are queried. From these, \nthe Prometheus metrics are generated. To complete the picture, the metrics are enriched with the labels from the resourcekind relationships \ncreated in the inventory.\n\n![](images/architecture.png)\n\nTo avoid multiple implementations of functionality, the collectors follow an inheritance structure.\n\n![](images/collectors.png)\n\n## Supported adapters and resourcekinds\n\nThis sections shows how vROps internal resourcekind relationsships are used in the exporter as a hierarchical tree.\n\n#### VMware vCenter Server\n\nResourcekind relationship:\n```shell\nVMwareAdapter Instance:\n    Datacenter:\n        VmwareDistributedVirtualSwitch\n        Datastore\n        ClusterComputeResource:\n            HostSystem:\n                Virtualmachine\n```\n\n#### VMware NSX-T Adapter\n\nResourcekind relationship:\n```shell\nNSXTAdapter:\n    ManagementCluster:\n        ManagementNode:\n            ManagementService\n        TransportZone:\n            TransportNode\n        LogicalSwitch\n```\n\n#### SDDC (Software-Defined Data Center) Health Adapter\n\nSDDC resourcekinds can be defined in [inventory-config](tests/inventory_config.yaml):\n\n```yaml\nresourcekinds:\n    sddc_resourcekinds:\n      - \"NSXT Server\"\n      - \"VCENTER\"\n      - \"NSXVPostgresService\"\n      - \"SSHService\"\n      - \"NSXReplicatorService\"\n      - \"NSXRabbitmqService\"\n      - \"NSXManagerService\"\n      - \"NSXControllerService\"\n      - \"SDDCHealth Instance\"\n      - \"vCenterBackupJob\"\n```\n\n#### VCOPS (vCenter Operations) Adapter\n\nVCOPS resourcekinds can be defined in [inventory-config](tests/inventory_config.yaml):\n\n```yaml\nresourcekinds:\n    vcops_resourcekinds:\n      - \"vC-Ops-Analytics\"\n      - \"vC-Ops-CaSA\"\n      - \"vC-Ops-Cluster\"\n      - \"vC-Ops-Collector\"\n      - \"vC-Ops-Node\"\n      - \"vC-Ops-Suite-API\"\n      - \"vC-Ops-Watchdog\"\n```\n\n## Running the software\n\n#### **inventory**\n\nThe inventory must be started with a specific `target`\n\n  * `--user`: specifiy user to log in\n  * `--password`: specify password to log in\n  * `--port`: specify inventory port\n  * `--target`: define target vrops\n  * `--config`: path to inventory config to set query filters (and resourcekinds - SDDC \u0026 VCOPS only)\n  * `--v`: logging all level except debug\n  * `--vv`: logging all level including debug\n  * `--loopback`: use 127.0.0.1 address instead of listen to 0.0.0.0 (for test purpose)\n  * `--sleep`: how often the resources are updated, default: 1800s\n\n\n#### **exporter**\n\nThe exporter must be started with a specific `target`. Optionally a specific `collector`, otherwise the `default_collectors` in [collector-config](tests/collector_config.yaml) were used.\n    \n  * `--port`: specify exporter port\n  * `--inventory`: inventory service address\n  * `--config`: path to config to set default collectors, statkeys and properties for collectors\n  * `--target`: define target vrops\n  * `--collector`: enable collector (use multiple times)\n  * `--rubric`: metric rubric in collector config\n  * `--v`: logging all level except debug\n  * `--vv`: logging all level including debug\n  \n  An example [collector-config](tests/collector_config.yaml). Add the desired `statkeys` and `properties` that your collectors should collect in a dedicated category. This is where `statkey` mapped to a `metric_suffix`. The `statkey` follows VMware notation (to make the API call) and the `metric_suffix` follows best practices as it should appear as a metric in prometheus.\n  \n  Metrics:\n [VMWARE Documentation | Metrics for vCenter Server Components](https://docs.vmware.com/en/vRealize-Operations/8.10/com.vmware.vcom.metrics.doc/GUID-9DB18E49-5E00-4534-B5FF-6276948D5A09.html)\n \n  Properties:\n [VMWARE Documentation | Properties for vCenter Server Components](https://docs.vmware.com/en/vRealize-Operations/8.10/com.vmware.vcom.metrics.doc/GUID-0199A14B-019B-4EAD-B0AF-59097527ED59.html)\n \n  Prometheus:\n [Prometheus | Metric and label naming](https://prometheus.io/docs/practices/naming/)\n \nIn addition, vrops-exporter is able to fetch alerts from supported resource types and wrap them in an info metric containing all symptoms and recommendations. \n\n```javascript\nvrops_hostsystem_alert_info{\n    alert_impact=\"HEALTH\", \n    alert_level=\"CRITICAL\", \n    alert_name=\"The host has lost connectivity to a dvPort\", \n    datacenter=\"datacenter1\", \n    description=\"One or more portgroups in the host lost connectivity to the dvPort. As a result, the services associated with the affected dvPorts are         \n        disconnected from the associated physical networks. All physical connections to the dvPort from the associated switch will become unavailable.\", \n    hostsystem=\"node001-prod1\", \n    recommendation_1=\"Replace the physical adapter or reset the physical switch. The alert will be canceled when connectivity is restored to the dvPort.\",      \n    status=\"ACTIVE\", \n    symptom_1_data=\"{'condition': {'faultEvents': ['esx.problem.net.dvport.connectivity.lost'], 'faultKey': 'fault|dvp|conn', 'type': 'CONDITION_FAULT'}, \n        'severity': 'CRITICAL'}\", \n    symptom_1_name=\"Lost network connectivity to DVPorts\", \n    vccluster=\"prod-cluster1\", \n    vcenter=\"vcenter1\"\n    }\n```\n \n\n###### **1. Build**\nTo build the container simply run `make` and get the locally created docker container.\n\n###### **2. CLI**\n\n   Either specify the vars via environment or cli params. Because the inventory and the exporter are running seperately,\n   you need to enter the Docker container at least twice.\n\nStart the container:\n\n       docker run -it keppel.eu-de-1.cloud.sap/ccloud/vrops_exporter /bin/sh\n\n   This will start the inventory container and directly enter the shell. Note, you need to define your vROps target beforehand [tests/inventory_config.yaml](tests/inventory_config.yaml#L1-L2).\n    \n       ./inventory.py --user foobaruser --password \"foobarpw\" --port 80 -m tests/inventory_config.yaml --vv\n    \n   Now you need to enter the container a second time:\n    \n       docker exec -it \u003ccontainer_name\u003e /bin/sh\n        \n   Now run the exporter:\n    \n       ./exporter.py --port 9000 --inventory localhost --config tests/collector_config.yaml --target 'vrops-vcenter-test.company.com' --vv\n       \n   You can also enter the container a third time to fetch the prometheus metrics from localhost (i.e. with wget)\n\n###### **3. Enviroment variables**\n\n    \n        USER\n        PASSWORD\n        PORT\n        INVENTORY\n        LOOPBACK\n\n\n## Running in Kubernetes\nFor running this in kubernetes (like we do), you might want to have a look at our [helm chart](https://github.com/sapcc/helm-charts/tree/master/prometheus-exporters/vrops-exporter)\n\n\n## Test\nTest module is called using ENV variables. Specifying these on the fly would look like this:\n\nMain test:\n```shell\nLOOPBACK=0 DEBUG=0 INVENTORY=127.0.0.1:8000 USER=FOO PASSWORD=Bar CONFIG=tests/collector_config.yaml TARGET=vrops-vcenter-test.company.com python3 tests/TestCollectors.py\n```\n\nTo run all tests you got to loop over it.\n```shell\nfor i in $(ls tests/Test*)\ndo\n  LOOPBACK=1 INVENTORY=\"127.0.0.1:8000\" DEBUG=0 USER=FOO PASSWORD=Bar python3 $i\ndone\n```\n\nPlease note that USER and PASSWORD are currently doing nothing at all, they are only passed on because the test\nchecks whether these are present.\n\nThe test generates dummy return values for the queries to vROps and checks the functionality of the collectors. \nIt compares whether the metrics as a result of the collector match the expected metrics in `metrics.yaml`. \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsapcc%2Fvrops-exporter","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsapcc%2Fvrops-exporter","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsapcc%2Fvrops-exporter/lists"}