i'm tempted to say that this is a dupe of ZBXNEXT-714 - the best would be for server to be able to push data to graphite, i guess
I'm wondering if it would be possible to expose the Zabbix API or Zabbix database as a Graphite storage finder/backend (http://graphite.readthedocs.org/en/latest/storage-backends.html). That way you don't double up your data storage. Zabbix can continue to gather the data and generate alerts and Graphite can do what it does best . . . draw pretty graphs.
If I have some spare time (hah!) I might have a go.
richlv, I always considered this request different from ZBXNEXT-714, because the description is about storing data additionally in a different storage backend. So Zabbix continues to work like before but something 3rd party got the data as well.
Now I admittedly share your opinion. A proper implementation of ZBXNEXT-714 would of course not only allow to store the data somehow somewhere else, it would also provide the interface for Zabbix accessing the data. In this case by querying the Graphite backend.
@Shane McEwan Did you ever pursue this? The biggest problem I have with Graphite is the single whisper db files.. Currently over 200,000 active files.. It's very high I/O. I'd love to use Zabbix with the ability to add graphite graphs - really would be the icing on the cake. 
As a proof of concept I wrote a little wrapper script in Perl that mimicked the Graphite API but spoke to the Zabbix API in the background. I then installed a few different Graphite compatible frontends and pointed them at my wrapper. Some of them partially worked but a lot were expecting more advanced Graphite API calls that I hadn't implemented. I realised that if I pursued this course I'd end up having to implement the entire Graphite API functionality which I didn't want to do so I abandoned it.
My next step is to try to write a functional Graphite storage backend that talks to the Zabbix API but my Python-fu is poor and the Graphite documentation assumes Python knowledge that I lack. But from my Perl wrapper tests and everything else I've read I don't see why a Graphite storage backend using the Zabbix API wouldn't work. It probably won't be fast, direct MySQL/PostgreSQL would be faster but more prone to breaking with Zabbix DB schema changes, but should be functional for small numbers of items and date ranges.
If there's any Python experts out there willing to help I'd be happy to stick what I've done so far (not much) onto Github and we can collaborate.
Shane McEwan,
Could you start a repo with what you've done so far? I as well as others on my team would love to get this going.
We've been able to use the pyzabbixapi to pull data into graphite with a custom python script, but its just creating duplicate storage due to the creation of the Whisper files.
We are using Grafana as our Graphite frontend, so we want to build a wrapper or data source for Zabbix that can be added to Grafana, this way it uses the Zabbix MySQL db for its data vs whisper.
I'll be more than happy to contribute on condition that the proper Apache v2 License be attached to your source.
ZBXNEXT-3353 asks for "module support for sending history data".