|
|
| Subject: | Zenoss metric names in opentsdb |
| Author: | Jim R |
| Posted: | 2015-05-13 09:06 |
What is the rationale for how metrics names are set in opentsdb in Zenoss 5
It looks like they are prefaced with the device name, which I would not expect. I would expect to use the datapoint name as the metric and then use a tag for the device name and component name.
Doesn't this risk causing problems by running out of metric names Also, it limits how you can perform aggregations across metrics.
I haven't yet looked into the internals that might require this, but I was hoping that someone might be able to answer this.
| Subject: | this is likely an opentsdb |
| Author: | Andrew Kirch |
| Posted: | 2015-05-15 10:23 |
this is likely an opentsdb dev hours question.
Andrew Kirch
akirch@gvit.com
Need Zenoss support, consulting or custom development Look no further. Email or PM me!
Ready for Distributed Topology (collectors) for Zenoss 5 Coming May 1st from GoVanguard
| Subject: | Is there an updated schedule |
| Author: | Jim R |
| Posted: | 2015-05-15 14:55 |
Is there an updated schedule for dev hours
| Subject: | Answer: because performance. |
| Author: | Jan Garaj |
| Posted: | 2015-07-18 13:53 |
Answer: because performance.
Opentsdb discussion:
but it led to extremely slow queries
opentsdb essentially does a table scan to find its metrics
Cardinality is how you tune how metrics are stored.
For 99% of queries made in a zenoss system, separating it by device is the best balance.
If your cardinality is very high (i.e., metric names are more generic), then your queries are very slow, but more flexible.
If your cardinality is very low (i.e., metric names are at, say, the component level), then your queries are very fast, but you have to build queries more on your own.
Separating them out by device matched nearly all the queries people make.
Its much better than RRDtool, because its just at the device level. You can, for example, aggregate bandwidth across all interfaces on a switch.
And building a query that specifically calls out device names isnt too arduous.
Devops Monitoring Expert advice:
Dockerize/automate/monitor all the things.
DevOps stack:
Docker / Kubernetes / Mesos / Zabbix / Zenoss / Grafana / Puppet / Ansible / Vagrant / Terraform /
Elasticsearch
| < |
Previous zenevend throwing alert complaining about "No such file or directory" -- missing ... |
Next control center services failing |
> |