Service Discovery for ZK-based Spring Cloud Services

[szhem]

Proposal

Use case. Why is this important?

Currently Prometheus has only two options to discover services from Zookeeper

• nerve_sd_config
• serverset_sd_config

We propose to implement one more popular option to discover services

• curator_sd_config

which will allow to discover services registered by means of Apache Curator Service Discovery extension (which is based on Zookeeper).

Zookeeper+Curator is also a popular way to register Spring Cloud Services which use Zookeeper as a Service Registry.

The way of organizing services in Zookeeper is described here and looks like the following

base path
       |_______ service A name
                    |__________ instance 1 id --> (serialized ServiceInstance)
                    |__________ instance 2 id --> (serialized ServiceInstance)
                    |__________ ...
       |_______ service B name
                    |__________ instance 1 id --> (serialized ServiceInstance)
                    |__________ instance 2 id --> (serialized ServiceInstance)
                    |__________ ...
       |_______ ...

The serialized ServiceInstance for Spring Cloud-based services is a json which looks like the following

{
    "uriSpec": {
        "parts": [
            {
                "variable": true,
                "value": "scheme"
            },
            {
                "variable": false,
                "value": "://"
            },
            {
                "variable": true,
                "value": "address"
            },
            {
                "variable": false,
                "value": ":"
            },
            {
                "variable": true,
                "value": "port"
            }
        ]
    },
    "name": "my-service-v1",
    "id": "ea68ba6a-5174-4669-bbe1-7b2b1a9cb425",
    "address": "server-n1",
    "port": 6161,
    "sslPort": null,
    "payload": {
        "metadata": {
            "instance_status": "UP"
        },
        "name": "my-service-v1",
        "id": "my-service-v1:6161",
        "@class": "org.springframework.cloud.zookeeper.discovery.ZookeeperInstance"
    },
    "registrationTimeUTC": 1519676776918,
    "serviceType": "DYNAMIC"
}

The address of the service is built from uriSpec.parts and then will be the following

{scheme}://{address}:{port}

// or

{scheme}://{address}:{sslPort}

// =>

http://server-n1:6161

The metrics endpoint can be discovered from the metadata (which is customizable)

"metadata": {
    "instance_status": "UP",
    "merticsPath": "/metrics"
}

and then they can be obtained using the following address of the service

{scheme}://{address}:{port}/{merticsPath}

// or

{scheme}://{address}:{sslPort}/{metricsPath}

// =>

http://server-n1:6161/metrics

[brian-brazil]

Thank you for your interest, I'm afraid that we're not accepting any new service discovery mechanisms currently. I suggest integrating via file_sd.

[szhem]

Hi @brian-brazil,

So new sd mechanisms will not be accepted even as pull requests?

[brian-brazil]

No, they won't be accepted currently. The maintenance burden of SD mechanisms is too high to take on any more I'm afraid.

[szhem]

Ok, thanks, then I'm closing this issue.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.