-
Notifications
You must be signed in to change notification settings - Fork 35
Add dyno name to host name #10
base: master
Are you sure you want to change the base?
Conversation
Hi @mezis! Thanks for the contribution. |
Mainly by giving the user the ability to see metrics by dyno. By default you'd constantly be averaging out, and could miss outliers — which can well be related to the code one runs, rather than the infrastructure. |
Is this usable? I think we're getting bad metrics since we have multiple web workers under the same app, trampling over each other. Host needs to be set so the metrics can be separated or even aggregated properly. |
I've been thinking about this approach, and I don't think it's the best idea. Here's some reasoning:
What about adding a |
In the datadog ui, there's the option with the requests metric to choose something to group by, and it's always "host", but for this buildpack, it's always blank. That's the "host" metadata that I'm thinking of. |
@konobi I don't think I follow - part of the setup for an app is setting a hostname in the config and it errors out otherwise. I tried today, and metrics emitted from inside the web worker show a |
okay... right now that HEROKU_APP_NAME is the name of the app... but you have multiple instances of that app on different dynos. So instead of |
@konobi I understand that - that's why I am proposing instead of munging the Then use can use the intersection of the existing |
k... that seems reasonable, assuming it's UI selectable =0) |
So it turns out that the I did make a viable workaround as an example (in ruby, other languages have similar env var approaches): $dyno_type ||= ENV['DYNO'].split('.').first
$statsd.increment('page.views', tags: ["dyno_type:#{$dyno_type}"]) This provides the "drop down" selection to be per-app (aka host) and dyno type. It's not perfect, but it's better than creating many "virtual" hosts (increases billing, makes it more difficult to maintain dashboards). I'll continue to explore a better method for this. |
any luck? |
I raised this issue with the Agent codebase, and they indicate that this mechanism is unlikely to be modified. I think it boils down to a couple of points:
If there are other ideas or perspectives that I'm not seeing, I welcome them. |
tags seems like a reasonable enough approach to me, though cost at the datadog end isn't nessecarily a factor for us specifically. |
Also, is there any documentation on how to configure kafkacat for use with ssl/tls? |
Optionally adds the dyno name to the hostname reported to Datadog.