Graphite

Completer should be able to search "better"

Asked by Pierre Baillet

Hi,

While I perfectly understand the .\*. syntax we generally use to generate aggregated graphs (and .*. for searches), I'd like to know if you plan to implement something that's more agile in term of search:

- Typing "*memory*" would bring up all the metrics matching memory ( such as servers.net.ftnz.virtual.infrabox.system.memory.* for example)
- Typing *.*_hits.* would bring up servers.net.ftnz.virtual.infrabox.Picor.picor_hits.*

This would definitely prove useful for systems where there are lots of metrics and nested paths for them.

Thanks for Graphite !
--
Pierre.

Question information

Language:
English Edit question
Status:
Answered
For:
Graphite Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
chrismd (chrismd) said : 		#2

The problem boils down to how the search is performed and how many metrics you have. The current solution uses filesystem glob patterns with a few tricks sprinkled in. This is a pretty efficient method. The webapp can search against an index file as well but that is very slow once you have more than a few tens of thousands of metrics. I actually tried implementing a preloaded index, stored in a tree structure that would support all the current search functionality plus more but it turned out to be a huge resource hog both in terms of memory and in terms of startup cost (which can be significant and somewhat frequent depending on your apache/wsgi config). I'm not saying a better search can't be implemented, just that I've tried and it's proven non-trivial.

Can you help with this problem?

Provide an answer of your own, or ask Pierre Baillet for more information if necessary.

To post a message you must log in.