Add a mode to surveyor where it subscribe to the server's id it is connected to.

[matthiashanel]

This way it will only receive it's local events, which will allow it to be deployed in the same way as the prometheus exporter.
Once we support this deployment model we can retire the prometheus exporter.

[ColinSullivan1]

We can deprecate the prometheus exporter with a suitable sunset period, and leave it open afterword.

As surveyor provides more comprehensive monitoring and features it'll be where efforts are focused moving forward. We understand that a migration will require user changes to their prometheus configurations and dashboards so we will be sensitive to that.

[matthiashanel]

potentially we can move some of the prometheus exporter parsing code into surveyor and make it a drop in replacement.

[ripienaar]

Even then people will have to move forward at some point as we will not be able to make this company later have new features without equal amount of work as managing both

I would just go for a clean break.

[ColinSullivan1]

Agreed - clean break is best imo.

[ripienaar]

This is actually quite hard to do in practise. The go nats client will always listen to server discovery and add discovered servers to the pool, you simply dont know if the nats client is connected to the server you had in mind.

So the only thing we can really do is say --serverid NB3LQCYTCZH66EWXYLMBIN5WYXGQGRK6FKFAPPDERR2DWP3HCRCGCXPA and have surveyor for ever more try to monitor that one ID, which will be flakey since IDs are not deterministic, so maybe --name fooserver and assume people will set name? I am still deeply convinced the default behaviour for name is wrong.

Does that sound reasonable? For sure saying monitor the server we're connected to won't be the right thing

[matthiashanel]

When we go for a name, wouldn't we have to try to suppress this behavior, just so we get the intended topology?

I would imagine that if you want to set up surveyor this way, you can be expected to set server_name.
However, what would happen if a server is restarted while a pod is still somewhat running? (possibly receive from two server)

Would it work to make use of NoReconnect? OR add a new option NoAllowDiscoveredServer intended for our use only.

[ripienaar]

If we do name based it would for as long as there is no dupes yeah. We should make sure that the servers stop responding to REQ during lame duck mode though

I doubt there is much appetite for turning off learning topologies in the libraries - though personally I would like such an option.