Graphite Flashcards
whisper
DB library storing time-series numeric data w/ create, update, fetch
carbon-cache
backend to store data points for metrics provided by clients
front-end webapp
renders graphs and provides bsic UI, custom graphs via URL params
metrics
unique name, with dot-separated hierarchy, e.g. servers.www01.cpuUsage
data point
(timestamp, value) pair corresponding to the measured value of a metric
Problem: Users’ dashboards w/ identical requests are pinning the CPU
- Render once & cache in memcached with even a few seconds expiry reduces burden significantly
- Cache underlying data so there’s less processing when a user tweaks and redraws graph
Problem: Volume of file writes exceeds ability of storage
- Seek time is the major bottleneck, even for whisper files 12 bytes in size, so write files contiguously to disk in a single write
- buffering queues added to carbon based on metric name
- adds resiliency to handle temp I/O slowdowns
- queues simply grow if system must perform other I/O work (as long as there is sufficient memory to hold the queues)
Problem:
Volume of queued data waiting for disk is noticeable to users who don’t see real-time data
- Added a socket listener to carbon to retrieve buffered data
- Webapp combines buffer + disk data and renders real-time graphs
Problem:
When kernel runs out of memory, writes become synchronous, which slows writes, grows queues, and everything screams
- Configurable limits on carbon: how big of queues, whisper rate limits
clustering
- find function was extended to be able to make remote HTTP calls to other graphite servers
- fetch for remote data also made available
- remote calls are the same as a client would call, except includes a param specifying that the operation should only be local & not redistributed throughout the cluster
efficiency
memcached the results of find requests
distribution
carbon-relay applies rules to determine which server to send metrics to