Observium Module

[norrchr]

Is there a Observium module in the pipeline?

 

Main features would be 95th/average/total bandwidth billing, bandwidth usage notification for users, the ability to suspend on overage or the ability to bill for overage daily or when over a predefined limit.

 

Willing to put some money into the pot if others would want such a module.

[Purevoltage]

Found this while hitting Google for a search, I'd be interested in something such as this as well.

[Paul]

We actually use observium here, and are planning an integration, haven't spent much time looking at it yet though, do they have an API? If they make it easy to obtain the data and graphs that would be awesome.

[Michael]

We actually use observium here, and are planning an integration, haven't spent much time looking at it yet though, do they have an API? If they make it easy to obtain the data and graphs that would be awesome.

 

A decent British company and here you go mate: http://observium.org/wiki/Configuration_Options#Simple_API_Settings

[Paul]

A decent British company and here you go mate: http://observium.org/wiki/Configuration_Options#Simple_API_Settings

 

That seems to show how to enable the API, but not how to interface with it.

[Michael]

That seems to show how to enable the API, but not how to interface with it.

 

Oh gay lol it says "All documentation on how to use this api is in the observium page itself when you enable this."  

[Blesta Addons]

That seems to show how to enable the API, but not how to interface with it.

 

what you search is here

 

https://github.com/talkingtontech/observium/tree/master/html/includes/api

[Paul]

I added some lines to my config.php file in observium, and got the API menu to appear with API docs for billing, inventory, packages, so we'll see how it goes. I wish we could export the actual graphs, but it looks like just the data.

[norrchr]

Paul, is there any updates on this?

In real need for such a module.

 

Another feature to add would be the ability to assign multiple ports to a single product with the ability to set overage prices per port like HostBill's observium module.

[Paul]

Paul, is there any updates on this?

In real need for such a module.

 

Another feature to add would be the ability to assign multiple ports to a single product with the ability to set overage prices per port like HostBill's observium module.

 

This is on our radar and we are doing some research and planning, but this will not be in development for a little while.

[Max]

We do have data traffic graphs that can be viewed by the customer in our (commercial) module.
It doesn't actually bill the overage though.

 

 

Another feature to add would be the ability to assign multiple ports to a single product with the ability to set overage prices per port like HostBill's observium module.

 

Be aware that combining ports is not that trivial when using the 95% billing method.

You cannot pull already computed numbers out of a monitoring program, and add them up.

If the monitoring program says port A did 10 mbit this month, and port B did 5 mbit, that does not mean you can bill 10+5 = 15 mbit.

No, the data traffic on the ports could have peaks at different times, and the real figure is somewhere between 10 and 15 mbit...

You would need to create a new graph combining all the individual data points from the RRD of port A and the RRD of port B, and use that to recalculate.

Tends to be easier to create combined graphs when collecting the data, instead of doing it afterwards...

[norrchr]

I'm looking to combine ports on total bandwidth model. I need to pull bandwidth usage from multiple regions and have separate overage billing per region but have them combined into and billed together under a single product line.

HostBill supports the combining with separate overage values under a single product via their observium module, but sadly no hourly/daily billing functionality in the module.

[Max]

I'm looking to combine ports on total bandwidth model. I need to pull bandwidth usage from multiple regions and have separate overage billing per region but have them combined into and billed together under a single product line.

HostBill supports the combining with separate overage values under a single product via their observium module, but sadly no hourly/daily billing functionality in the module.

 

The way Hostbill adds up ports is fine if you are billing by total traffic in TB.

 

You also mentioned the desire for 95 percentile billing in your initial post though.

That cannot be done in the same way, or you would overcharge the customer. Need aggregate graphs to do that right.

[Paul]

The way Hostbill adds up ports is fine if you are billing by total traffic in TB.

 

You also mentioned the desire for 95 percentile billing in your initial post though.

That cannot be done in the same way, or you would overcharge the customer. Need aggregate graphs to do that right.

 

Do you have some use-cases / examples of why aggregating ports for billing would be preferable for a situation? It seems like most of the time, especially with colo, billing per-port would be ideal. I suppose if you were selling dedicated servers where the customer doesn't have their own switch and drop, and offered a bandwidth plan for the entire account this would make sense but I'm not sure how prevalent that is.

[Max]

Do you have some use-cases / examples of why aggregating ports for billing would be preferable for a situation? It seems like most of the time, especially with colo, billing per-port would be ideal. I suppose if you were selling dedicated servers where the customer doesn't have their own switch and drop, and offered a bandwidth plan for the entire account this would make sense but I'm not sure how prevalent that is.

 

Typical use-case would be colocation by the rack instead of by the unit.

Most colo providers here provide 2 uplinks to your own switch for redundancy.

 

For illustrative purposes, attached the graph for one of our own racks at a large colo provider.

As you can see, there are two switch ports

Due to the network configuration used one is mostly doing incoming, and the other doing mostly outgoing traffic.

 

They are combined into one aggregate graph, and that one is used for billing.

Results in a charge for 8 mbit of datatraffic according to the 95 percentile method.

If the graphs were calculated separately, the charge would be more (and we would have unplugged one cable :-) )

[Paul]

Typical use-case would be colocation by the rack instead of by the unit.

Most colo providers here provide 2 uplinks to your own switch for redundancy.

 

For illustrative purposes, attached the graph for one of our own racks at a large colo provider.

As you can see, there are two switch ports

Due to the network configuration used one is mostly doing incoming, and one is mostly doing mostly outgoing traffic.

 

They are combined into one aggregate graph, and that one is used for billing.

Results in a charge for 8 mbit of datatraffic according to the 95 percentile method.

If the graphs were calculated separately, the charge would be more (and we would have unplugged one cable :-) )

 

Thanks for the details. I'm curious, how do they route both of those ports? Are they both just part of the same VLAN?

[Max]

Thanks for the details. I'm curious, how do they route both of those ports? Are they both just part of the same VLAN?

 

In order to also get router redundancy (not just network link), one network cable goes from our switch (directly or indirectly through another switch) to router A, the other to router B.

Network architecture isn't part of my job, but my understanding is that the routers talk to each other using a protocol like HSRP or VRRP and decide which one plays default gateway for our servers, and responds to ARP requests from our servers trying to get the MAC of the default gateway IP.

Only one router at a time handles traffic from our servers to the Internet, that's why you only see a green line in one of the graphs.

However both can forward traffic from the Internet to our servers.

Servers do not care very much where incoming traffic comes from, it doesn't have to come from the MAC of the default gateway.

Not sure what routing policy setting exactly causes that the incoming traffic is send mostly over the router connected to the other port -it can come from both- but apparently the routers decided that was the shortest/least-congested path.

 

[Adam]

Howdy Folks,

 

Has any progress been made on the observium front? We currently use a mix bag of monitoring programs, everything from Nagios to Observium to paid for monitoring services and home made scripts. Part of our process, besides evaluating moving to a newer billing and ordering software is to integrate one of these services to the customer facing side. We are currently looking at Icinga and Observium as final choices. Knowing about the observium front will help us make a wide number of decisions.

 

Let us know! thanks,

-Adam

[Blesta Addons]

We are Working in the module for some clients with custom request, after we finish it we will make it with standard features to feat anyone needs, and we will make it available for all the publics .

any ideas or observation about how it should work is welcome .

[Blesta Addons]

we have finished the module now, is tested and working perfectly , we have also included the graphs in the admin/client service info .

we are now developing the helper plugin for counting the extra overuse bandwidth , we will include calculation for 95th and cdr (quota type) . and to get that data we should work the stored RRD files , any one has a reference for a already request to get the data for certain period ?

[si458]

please can the plugin be updated for PHP 7.0+ support

i have sent a few tickets in to the blesta-addons support but you keep saying it is php7.0 ready when it isnt

[2018-10-27 22:38:17] general.ALERT: Fatal Error (E_COMPILE_ERROR): 'continue' not in the 'loop' or 'switch' context {"code":64,"message":"'continue' not in the 'loop' or 'switch' context","file":"/var/www/blesta/plugins/observium/models/observium_billing.php","line":198}

[Sat Oct 27 22:49:21.721052 2018] [:error] [pid 21696] [client 217.28.xxx.xxx:50634] PHP Fatal error: The file /opt/observium/html/bl_api.php was encoded by the ionCube Encoder for PHP 5.4 and cannot run under PHP 7.0.\n Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown on line 0

[Blesta Addons]

On 10/27/2018 at 11:02 PM, si458 said:

please can the plugin be updated for PHP 7.0+ support

i have sent a few tickets in to the blesta-addons support but you keep saying it is php7.0 ready when it isnt

[2018-10-27 22:38:17] general.ALERT: Fatal Error (E_COMPILE_ERROR): 'continue' not in the 'loop' or 'switch' context {"code":64,"message":"'continue' not in the 'loop' or 'switch' context","file":"/var/www/blesta/plugins/observium/models/observium_billing.php","line":198}

[Sat Oct 27 22:49:21.721052 2018] [:error] [pid 21696] [client 217.28.xxx.xxx:50634] PHP Fatal error: The file /opt/observium/html/bl_api.php was encoded by the ionCube Encoder for PHP 5.4 and cannot run under PHP 7.0.\n Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown on line 0

Hello SIr

we have the php 7 version but we hvn't yet released it, because exist some issues we need to fix them, but definitely we are going with until and soon we will release it and make EOF for 5.4 series .

 

[si458]

2 hours ago, Blesta Addons said:

Hello SIr

we have the php 7 version but we hvn't yet released it, because exist some issues we need to fix them, but definitely we are going with until and soon we will release it and make EOF for 5.4 series .

 

ticket #4885952 i submitted a new one last night before posting here, and have included links to these forums

im happy to test the new files for you