Closed nitin02 closed 1 year ago
This is a great idea. I am working on a revamp to the configuration system which will allow for the creation of config plugins #272, once this is complete then this should be possible to write.
@danielnelson have you finished your plugins? nowtime, I have a project want to use Telegraf to support Eureka . if I want to use your plugins, how can I do ?
I have wrote a java project to solve this problem. the project can find all the project register in eureka ,and renew the relegraf.conf real time. at last ,it will restart telegraf ,so we can get all projects in grafana. you can refer to my java project : https://github.com/shindoyang/telegraf_plugin-of-eureka
@shindoyang Sorry, work on the config plugins has been on hold for awhile now. It may be some time still before we can complete it. Glad you have a working solution and thanks for sharing the link.
Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Forums or provide additional details in this issue and reqeust that it be re-opened. Thank you!
Proposal:
Using the Service Discovery layer to get the IP, Port, Custom Jolokia context.
For example, spring boot admin (https://github.com/codecentric/spring-boot-admin) directly uses the spring cloud discovery component (Ex. Netflix Eureka) to identify the instance/management information and use it for fetching all jmx stats and others. This is because the context/IP/Port varies for every service and can never be known until startup.
(http://codecentric.github.io/spring-boot-admin/1.5.2/#discover-clients-via-spring-cloud-discovery)
The same thing can be done for tomcat stats too -- fetching the manager url through discovery (or any other service level stats).
https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html
Current behavior:
Jolokia plugin requires a jolokia context with a IP and port configured. Such type of hard-code (or even a limited dynamic implementation with environment variables) is undesirable as,
In production environments, -> A instance may run one or many services exposed with multiple ports and multiple jolokia contexts (for example, with multiple docker containers). -> The port of the web application can be randomly chosen on startup, AWS ECS supports this. This makes it even more difficult to configure telegraf. -> service registry layer has access to all instances to fetch all necessary information.
Desired behavior:
The desired behavior should be to have plugin with input as the service registry IP and port (as done with the spring-boot-admin example; eureka url). Only one instance of telegraf would be sufficient, in that case to capture stats from all services.
Use case:
Every production environment ideally has a service discovery/registry layer which is used for auto-scaling, customized deployment of services, load-balancing and the like. Hard coding an IP/port/URL is a simple solution for traditional cases but will fail for advanced usage in production environments. Hence, it should be of priority to use one.