# Provider Uptime



## Mun (Aug 12, 2014)

Do any providers post uptime and stats of their nodes? Could you give me examples?

I am looking for something like :


```
{"uptime":"3903931","total_memory":"7813516","free_memory":3001640,"disk_total":518137503744,"disk_free":189112705024,"load_average":7.64,"rx_bandwidth":"0","tx_bandwidth":"0"}
```


----------



## fm7 (Aug 12, 2014)

http://www.ramhost.us/?page=status

http://www.gplhost.com/gfx/snaps/rrdtool_server_usage.png http://www.gplhost.com/software-dtc.html

http://status.ovh.com/

http://status.ovh.com/vms/

http://weathermap.ovh.net/


----------



## Mun (Aug 12, 2014)

fm7 said:


> http://www.ramhost.us/?page=status
> 
> http://www.gplhost.com/gfx/snaps/rrdtool_server_usage.png http://www.gplhost.com/software-dtc.html
> 
> ...


I mean node specific. I'm not looking for their monitors at all. I am looking for where there monitors get the data.


----------



## mtwiscool (Aug 12, 2014)

Mun said:


> I mean node specific. I'm not looking for their monitors at all. I am looking for where there monitors get the data.


32MB Club node Adam and Eve: http://uptime.statuscake.com/?TestID=r6oIYH88lI


----------



## Mun (Aug 12, 2014)

<.<

sigh.


----------



## Aldryic C'boas (Aug 12, 2014)

Let's add to the food for thought train:

900 second check intervals.  15 minutes.  Someone smart enough to pretend to be retarded in order to get pity/etc would have the public monitor check every 15 minutes, with a second monitor on a much shorter interval.  Second monitor would give alerts to downtime, and 15 minutes is plenty of time to either fix the problem or say _sod it_ and just reboot the node - with time to spare before the next public monitor check.  BAM, _"100% Uptime"_ achieved.


----------



## Mun (Aug 12, 2014)

aldryic does frantec have an uptime.php on there servers or is that long gone with buyvmstatus.com


----------



## Francisco (Aug 12, 2014)

Mun said:


> aldryic does frantec have an uptime.php on there servers or is that long gone with buyvmstatus.com


Buyvmstatus never had it and was based on pings from outside the network. It was common for nodes to get

nulled when people couldn't take down filtered IP's so it would throw reports off. We'd have users that would

monitor the node ping or go off buyvmstatus and then cry for SLA, even though their own pingdom monitors would

show no downtime for the entire month.

I considered getting pingdom going for all of our nodes but again, we run into the same issue with nullroutes.

One option would be to just hide the traceroute hop's for people and just write a statistics proxy page.

I've not put much thought into it as I've not sat down and worked out how I want statistics done in Stallion,

but they'll happen soon (after the Staminus integrations though).

At some point i'll write a proxy into stallion 2 so we can have a public page for the details.

I don't think you'll find many providers willing to feed you TX/RX, memory, cpu, etc.

Uptime shouldn't be a big deal.

Francisco

EDIT - Fixing my name since I franned up while typing the last 2 parts.


----------



## Aldryic C'boas (Aug 12, 2014)

Mun said:


> aldryic does frantec have an uptime.php on there servers or is that long gone with buyvmstatus.com


BuyVMStatus was never actually a project of ours - a client ran it, and because it was a single-source and external based, there were all kinds of false positives.  Eventually just had to get the guy to take it down because I was getting a ridiculous number of invalid SLA claims.


----------



## Mun (Aug 12, 2014)

Francisco said:


> Buyvmstatus never had it and was based on pings from outside the network. It was common for nodes to get
> 
> 
> nulled when people couldn't take down filtered IP's so it would throw reports off. We'd have users that would
> ...


Hmm, couldn't someone get a server inside buyvm's to locations and ping from there? Or would that not work. Not sure how your internal network structure works.


----------



## Francisco (Aug 12, 2014)

Mun said:


> Hmm, couldn't someone get a server inside buyvm's to locations and ping from there? Or would that not work. Not sure how your internal network structure works.


Sure but that wasn't done.

With the old LV router nullroutes weren't enforced internally so you could still contact the nodes while it's nullrouted to the world (quagga being sloppy with network imports). With the brocade that isn't possible without being REALLY sloppy, though, so it won't work.

Francisco


----------



## Mun (Aug 12, 2014)

So, if I wanted to build a buyvmstatus page, which I know you would say no to I'd really need to buy two small servers, one for each location, and import that data to a separate off site server for better accuracy on nodes?

The reason I am asking is brocade comment made it sound like it is no longer possible.


----------



## Francisco (Aug 12, 2014)

Mun said:


> So, if I wanted to build a buyvmstatus page, which I know you would say no to I'd really need to buy two small servers, one for each location, and import that data to a separate off site server for better accuracy on nodes?
> 
> The reason I am asking is brocade comment made it sound like it is no longer possible.


That still wouldn't work because IP's are nullrouted both internally and externally. 

NJ's got a brocade on the way sometime soon, I'm just waiting to get it tested first.

Francisco


----------



## Mun (Aug 12, 2014)

Francisco said:


> That still wouldn't work because IP's are nullrouted both internally and externally.
> 
> 
> NJ's got a brocade on the way sometime soon, I'm just waiting to get it tested first.
> ...



Well DAMN!

You are making it hard to monitor


----------



## Mun (Aug 12, 2014)

I was wanting to build a provider uptime list showing multiple providers and if there stuffs were up. Not sure that is really possible at this point.


----------



## DomainBop (Aug 12, 2014)

> I don't think you'll find many providers willing to feed you TX/RX, memory, cpu, etc.
> Uptime shouldn't be a big deal.


Providers who suffer from epenis node inflation syndrome and slabbilitis are unlikely to feed him uptime info on their nodes...just sayin'.


----------



## Mun (Aug 12, 2014)

DomainBop said:


> Providers who suffer from epenis node inflation syndrome and slabbilitis are unlikely to feed him uptime info on their nodes...just sayin'.



I sorta figured that might happen, but I was trying to create a way so that people could see that there were issues or not with X provider. Simply, if you don't have anything to hide then it shouldn't be a problem.


----------



## KuJoe (Aug 12, 2014)

https://my.securedragon.net/serverstatus.php

http://status.securedragon.net

The first one pulls from the uptime command (can you guess when the last critical kernel patch was ) and the 2nd one is NodePing, our primary external monitor.

I plan on integrating them back into http://drgn.biz when I get around to it.


----------



## Mun (Aug 13, 2014)

KuJoe said:


> https://my.securedragon.net/serverstatus.php
> 
> http://status.securedragon.net
> 
> ...


how does your app get the data, uptime.php? or does it SSH in and get the uptime command?


----------



## KuJoe (Aug 13, 2014)

Mun said:


> how does your app get the data, uptime.php? or does it SSH in and get the uptime command?


I took the status.php file that comes with WHMCS and re-wrote it. I plan on expanding on it a lot more but it's not a huge priority compared to other things on my ToDo list.


----------



## Mun (Aug 13, 2014)

aww ok


----------

