Flashcards in Graphite Deck (12):
1

whisper

DB library storing time-series numeric data w/ create, update, fetch

2

carbon-cache

backend to store data points for metrics provided by clients

3

front-end webapp

renders graphs and provides bsic UI, custom graphs via URL params

4

metrics

unique name, with dot-separated hierarchy, e.g. servers.www01.cpuUsage

5

data point

(timestamp, value) pair corresponding to the measured value of a metric

6

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

7

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)

8

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

9

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

10

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

11

efficiency

memcached the results of find requests

12

distribution

carbon-relay applies rules to determine which server to send metrics to