I have this simple script6 which works:

:local i
:foreach i in=[/queue simple find name!="AllQueues"] do={:put ( "IP: " . [/queue simple get $i target-addresses] . "\tBytes: " . [/queue simple get $i bytes] . "\t");}

It generates a chart with the target-addresses and the bytes they've used, but it prints it out to the console.

What I want is to generate the chart and email it. I tried creating the chart in memory like this:
:local i
:local chart;
:foreach i in=[/queue simple find name!="AllQueues"] do={:set chart ( $chart . "IP: " . [/queue simple get $i target-addresses] . "\tBytes: " . [/queue simple get $i bytes] . "\t");}
:/tool e-mail send subject="Queue Stats" to="xxx@xxx.xxx" body=$chart from="xxx@gmail.com" tls=yes port=587 server="74.125.131.109"

And it crashed the router due to a memory overflow. So that is clearly the WRONG way to do it. Any ideas on how I can make this work? I'd prefer not to generate a file as that causes a write to Flash and I want to minimize flash-writes.

You could send the data to an external HTTP/FTP server, where a separate program would read that data, generate the chart and email it. Alternatively, you could make a program on a separate device that connects to the router using the API protocol, and generates a chart based on the "live" data.

In either case, we're talking about the generation happening off the router, which is the important bit.

I realised last night as I nodded off to sleep that I could run the script and replace the put instruction with a fetch instruction which would then send the data to a web-server script which would then store it into a database for me, which is where I want it to end up anyways.

I had also thought about the API method as well, but I'm less keen on that one. For the most part, I have the API interface disabled on the router since it is the gateway connected directly to the internet. Even with IP filtering, I don't trust it to not be messed with.

I could also use SNMP, but since I haven't found a way to predict the SNMP OID number for each queue, I'm really not keen on that option either. While I can get the OID for each queue in a file, it's not in a form that is easy to import into a database.

So I think the fetch will be what I will use.