Statistics Offloading
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
- ecrist
- Forum Team
- Posts: 237
- Joined: Wed Nov 26, 2008 10:33 pm
- Location: Northern Minnesota, USA
- Contact:
Statistics Offloading
It would be nice if OpenVPN allowed for script calls during status log updates. The concept would be to submit the data: Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since as arguments to a shell script. This would allow for posting to a database or other store for use in monitoring, billing, etc.
OpenVPN Community Administrator
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
- krzee
- Forum Team
- Posts: 728
- Joined: Fri Aug 29, 2008 5:42 pm
Re: Statistics Offloading
couldnt a script hook into the management interface to get that info at whatever interval you decide?
- ecrist
- Forum Team
- Posts: 237
- Joined: Wed Nov 26, 2008 10:33 pm
- Location: Northern Minnesota, USA
- Contact:
Re: Statistics Offloading
Yes, but it's a 'I hope it catches it.' in the timing. In a perfect world, the cron/whatever call that runs data collection would never fail, or would land cleaning between updates to that status file. However, it would be ideal to simply put that data directly somewhere more useful (such as a database).
OpenVPN Community Administrator
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
- dazo
- OpenVPN Inc.
- Posts: 155
- Joined: Mon Jan 11, 2010 10:14 am
- Location: dazo :: #openvpn-devel @ libera.chat
Re: Statistics Offloading
Just to be sure I understand it correctly ... Now, openvpn provides this information (bytes_sent, bytes_received, session_duration, etc) via the --client-disconnect hook. And you want an extra hook, which is called whenever the --status file is called? So that you can see the bytes_sent/received on open/active sessions?
For what it's worth, from the database eurephia uses, it's possible to extract the following information via simple SQL query. But now it's only the saved when --client-disconnect happens.
(this is just a parts of the information available, but related to this discussion I believe)
If I have understood it correctly, I believe this should be doable to implement. As I believe the status file do have these counters available, it shouldn't be too much work managing that.
For what it's worth, from the database eurephia uses, it's possible to extract the following information via simple SQL query. But now it's only the saved when --client-disconnect happens.
Code: Select all
common_name = John_Doe
email = john.doe@example.com
remotehost = 111.222.112.215
macaddr = 54:8d:1c:57:32:3c
vpnipaddr = 10.8.0.11
sessionstatus = 4
login = 2010-01-10 17:51:55
logout = 2010-01-10 23:27:20
bytes_sent = 4176565
bytes_received = 1582211
session_duration = 20127
If I have understood it correctly, I believe this should be doable to implement. As I believe the status file do have these counters available, it shouldn't be too much work managing that.
- ecrist
- Forum Team
- Posts: 237
- Joined: Wed Nov 26, 2008 10:33 pm
- Location: Northern Minnesota, USA
- Contact:
Re: Statistics Offloading
You're right, but I want these stats on live connections. It is workable now to use a collector (via cron/whatever) and then use a script for client-disconnect to wrap up the data, but it's not efficient or ideal, in my opinion.
OpenVPN Community Administrator
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
- dazo
- OpenVPN Inc.
- Posts: 155
- Joined: Mon Jan 11, 2010 10:14 am
- Location: dazo :: #openvpn-devel @ libera.chat
Re: Statistics Offloading
I have poked quickly into the code, and I believe I see two possible approaches.
1) --status-script <script>
This script will be called each time the status file is updated. It can provide a full path to the status log as a parameter. This approach is more a kind of a trigger mechanism.
2) Via the --plugin interface
Going this way will be a bit more work, but I consider it just as important. The C plug-in can then indicate that it wants to be called during status updates. One way to do this, could be that each record (line) in the status file would be formatted and the plug-in function would then be called for each record. This would give least processing time, as data could be more nicely be formatted. To manage such "in-memory record transfer" would require the plug-in interface to be extended in some way. It might be that a new plug-in API would be to be designed.
For the alternative 2), it would be beneficial also to support status updates without writing it to a file, so that only the records could be transferred only in memory. Which again would require some re-factoring of the status update logic.
I would also recommend an implementation which does both the alternatives, both a trigger script and C plug-in.
1) --status-script <script>
This script will be called each time the status file is updated. It can provide a full path to the status log as a parameter. This approach is more a kind of a trigger mechanism.
2) Via the --plugin interface
Going this way will be a bit more work, but I consider it just as important. The C plug-in can then indicate that it wants to be called during status updates. One way to do this, could be that each record (line) in the status file would be formatted and the plug-in function would then be called for each record. This would give least processing time, as data could be more nicely be formatted. To manage such "in-memory record transfer" would require the plug-in interface to be extended in some way. It might be that a new plug-in API would be to be designed.
For the alternative 2), it would be beneficial also to support status updates without writing it to a file, so that only the records could be transferred only in memory. Which again would require some re-factoring of the status update logic.
I would also recommend an implementation which does both the alternatives, both a trigger script and C plug-in.
- ecrist
- Forum Team
- Posts: 237
- Joined: Wed Nov 26, 2008 10:33 pm
- Location: Northern Minnesota, USA
- Contact:
Re: Statistics Offloading
I like option one best. This is how Nagios handles check scripts, data is passed to the application as arguments on the command line. If there was a possibility of exceeding the 255 chars on the command line, it would be possible to call the script and put the data in the environment for retrieval, similar to how OpenVPN handles up/down scripts now.
OpenVPN Community Administrator
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN
-
- OpenVpn Newbie
- Posts: 1
- Joined: Fri Dec 03, 2010 2:01 am
Re: Statistics Offloading
The concept would be to submit the data: Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since as arguments to a shell script. This would allow for posting to a database or other store for use in monitoring, billing, etc.
save environment
save environment