You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our setup we end up with a ton of new keys every time we redeploy our topologies because executor ids, hostnames, worker ports, etc.. all change. As a result our graphs end up having to wildcard a lot of keys in order to work from deploy to deploy. It seems like if it was possible to customize what key space was generated, we could eliminate the bits we don't care about.
I've created #31 to provide a way to customize the generated graphite key space. To keep backwards compatibility, this solution is a bit messier than say if I just overloaded the "metrics.graphite.prefix" to handle this. If backwards compatibility isn't such a big deal, I can refactor this and clean it up a bit.
The text was updated successfully, but these errors were encountered:
Although I realize now in order for this to work correctly, I may need to also combine now non-unique keys before sending them over to graphite. This may require a bit of tinkering.
In our setup we end up with a ton of new keys every time we redeploy our topologies because executor ids, hostnames, worker ports, etc.. all change. As a result our graphs end up having to wildcard a lot of keys in order to work from deploy to deploy. It seems like if it was possible to customize what key space was generated, we could eliminate the bits we don't care about.
I've created #31 to provide a way to customize the generated graphite key space. To keep backwards compatibility, this solution is a bit messier than say if I just overloaded the "metrics.graphite.prefix" to handle this. If backwards compatibility isn't such a big deal, I can refactor this and clean it up a bit.
The text was updated successfully, but these errors were encountered: