Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow extending surfacers as extensions #661

Open
jumpojoy opened this issue Dec 31, 2023 · 2 comments
Open

Allow extending surfacers as extensions #661

jumpojoy opened this issue Dec 31, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@jumpojoy
Copy link
Contributor

Implement surfacer extension interface
At the moment it is possible to extend surfacers via user defined surfacer type. But unfortunately this way is not flexible enough when it is required to pass additional configuration to the surfacer. It would be good to implement surfacer extension similar to probes.

@jumpojoy jumpojoy added the enhancement New feature or request label Dec 31, 2023
@manugarg
Copy link
Contributor

manugarg commented Jan 7, 2024

Hello @jumpojoy,

We didn't feel the need for surfacer extensions because extensions are truly useful when you want to have multiple types of them in a single process. For example, if you define a redis probe extension, you may run multiple redis probes with slightly different parameters within the same process.

On the other hand, if you implement a new surfacer type, you can take its configuration at the binary level. For example, if you're adding let's say a Dynatrace surfacer, you can take Dynatrace config at the binary level .. either through environment variables or flags. Extension will be useful if you want to define multiple Dynatrace surfacers, each with slightly different config.

Does it make sense? If you can explain your use case a bit more we can prioritize it better.

Thanks,
Manu

@jumpojoy
Copy link
Contributor Author

Hello @manugarg !

Thanks for quick reply.

I do not think that we need multiple types of same surfacer in one processes, I've missed this is a difference also.

We are trying to use cloudprober as a monitoring for OpenStack (this is opensource cloud technology). The user workloads there running in fully is isolated private networks, under the hood (depend on the networking driver) the network is an abstraction represents as linux network namespace. So we starting a cloudprober instance for each OpenStack network (linux network namespace). Later we aggregate metrics from all cloudprober instances. Custom surfacer stores metrics in a files in json/yaml format. So we can easely read all files and make combined output.

We already pass configuration externally to the surfacer this works for sure, but I was thinking that idea of implementing an ability to extend surfacer configuration with protobuf extension makes sense.

Thanks,
Vasyl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants