Tag Info

Hot answers tagged

25

Can "any" server handle it? Probably. Should you do it? Probably not. Ask yourself a few questions: How fast will you be to respond to an outage? How many pageviews do you normally receive per second? How many consecutive errors are you willing to see before calling it "Down" and sending an alert? Do you have any SLA with internal or external ...


24

Your registrar is, IMHO, the least of your concerns. Your actual DNS provider (the folks who host your nameserver) is probably worth a little consideration, but it's still down in the noise compared to the rest of what you need to do to really reach 99.9999% availability. Six Nines availability (99.9999) means less than 1 hour minute (actually exactly ...


22

One of my favorite distribution-agnostic tricks is to check the inode change time of files or directories which are extremely unlikely to ever have been altered over the life of the server. These are generally directories in the root directory, such as /lost+found. For example, this Ubuntu 10.04 LTS system was indeed installed around 9:40 pm on February 1, ...


13

Is it your goal to reach 6 nines of uptime or is someone else mandating it to you? If it's your goal, then it's admirable but unrealistic, improbable, and next to impossible. If it's being mandated to you then the entity that has made the mandate is woefully unaware of what it really means, what it would cost to achieve, and is likely just regurgitating ...


11

If you're on a distribution that uses Anaconda, you can look at /root/install.log. edit: It appears you're using Debian. Debian places its install log into /var/log/installer.


10

Real 100%? No. Five nines (99.999%)? Yep. Five nines is about five minutes unscheduled outage/year. You can get more reliability if you want, but five nines is where the cost for increased reliability is really taking off. You can approximate four nines as less than an hour outage/year, three nines as less than nine hours and six nines as about half a ...


10

Ping only checks if the remote host is answering ICMP packets, which (usually) means it's up and running; but this doesn't give you any information about which services the host is actually offering. An HTTP GET request checks that there is a web server running on the host, that it answers to a given IP/port/hostname combo, that you asked it for a valid URL ...


8

You're thinking about this the wrong way. You shouldn't care if the server is down, you should care if the service that it is offering is down. The offered service is purely conceptual. It could be composed of one or many actual technologies like HTTP, HTTPS, SSH or whatever else you are leveraging. Don't monitor the server - monitor the service. If you're ...


7

You can use wget in a script like this wget --timeout=3 --tries=1 --spider --no-check-certificate http://serverfault.com if [ $? -ne 0 ];then echo "Site Down" | mail -s "Site Down" admin@yourdomain.com fi And you will get an email if wget cannot access the site first time within three seconds. Set up a cron job to run the script every few minutes. ...


7

If you don't want to use cron, you could also create a directory in /dev/shm. Since that location is in memory, it will always be empty when the computer starts up. If it's not empty, you haven't rebooted.


7

The remote server is not under your control/responsibility In this case you can only guess if the remote server is up using network tools. If the website you are trying to check is public, you can use a third-party to check for you. The remote server is under your control/responsibility if this is a physical machine, it probably has some DRAC, iLO, HMC ...


6

If you're worrying about your dns/registrar instead of your 4 redundant data centers, your 8 redundant ISPs (two different pipes at each datacenter), and your trans-continental clustering failover hardware/software solution, you're looking in the wrong place. Six nines is basically impossible. You can be down for no more than 30 seconds each year. 30 ...


6

You have many options, I'll give you two. Nagios is a full-blown monitoring application capable of monitoring much much more than http, but it handles that as well. It can also create all kinds of repots ("Tell me the uptime percentage of our server/service X this week/month/year...") Monit is another popular choice. Maybe not as feature-filled as Nagios, ...


6

You could use netcat if there is a Windows version - on Linux I use: nc -z <host> <port> This returns 0 if the port is open. Run this in a loop for make it continuous. If Powershell is available, see http://poshcode.org/85 for an example.


6

Is there a way to make it so that if sub.domain.com on server A is unavailable, forward to server B until A comes online? Not via DNS - at least not without a custom DNS server monitoring and changing records on the fly (which wouldn't work too well). To get this behavior, you'll need a system in between the clients and the servers handling the ...


6

My rule-of-thumb for clients is: two nines you get for free. Every extra nine increases cost by up to an order of magnitude. That is to say, you can have 99% uptime by just putting your application on a half-decent server on your corporate internet connection. To improve on that, you can colocate. You can colocate with load-balancing and fast failover. ...


6

According to https://github.com/aws/opsworks-cookbooks/pull/40 and consequently http://www.mail-archive.com/haproxy@formilux.org/msg06885.html you can: iptables -I INPUT -p tcp --dport $PORT --syn -j DROP sleep 1 service haproxy restart iptables -D INPUT -p tcp --dport $PORT --syn -j DROP This has the effect of dropping the SYN before a restart, so ...


5

There is no such thing as 100% uptime. Software breaks, hardware fails, and you can only mitigate these to a certain extent. Cloud computing is a misnomer, because it still relies on a hardware/software backend. That being said, I'm sure there are companies out there who have taken the necessary precautions to minimize the chance and duration of an ...


5

Personally I'm not a fan of rebooting servers (except my terminal servers) unless there's a need for it.


5

There are some things to consider in all of this. Why did the outage happen? (Is it just your server that was hosed or their entire datacenter? If it was a larger outage, like a whole datacenter or their entire WAN connection, then you should be less forgiving. If it was a single node, then maybe you can be less austere in your judgement.) What has been ...


5

Create a directory somewhere when the system starts. When your script runs if the directory exists then the system has restarted otherwise not. Get your script to remove the directory. Use the @reboot directive in /etc/crontab to create the directory when the system starts.


5

Things like waiting on I/O don't take any CPU time but can block other processes from running.


5

If you don't want any downtime, then really the only option is to build your new install on separate hardware and when you're happy that it's all working correctly, alter your DNS settings to point to the new server. If you don't have another physical server, you might consider running your app on a cloud server while you do the upgrade of your physical ...


5

When you pay for hosted monitoring (even just a basic uptime/ping solution) you're paying for three principle things: The pretty reporting interface these services usually offer (Because you have to show this stuff to the big bosses and justify the cost!) The uptime/availability of the service provider (Because what good is it if your monitoring system is ...


5

Well there isn't really an uptime of openssh. you can check that it is active or how many connections it has. Or can grab the last time it was restarted by looking at /var/run/sshd.pid ls -l /var/run/sshd.pid -rw-r--r-- 1 root root 4 2012-12-15 21:26 /var/run/sshd.pid That file is updated when the daemon starts/restarts. So you can calculate based on ...


5

So you actually are using a lot of CPU. Either get a better server or make your forums become less popular. You also seem to be sending quite a bit of mail... is your forum hacked and is somebody using it as a spam source? Check your mail logs...


5

Apache isn't being restarted (which implies shutting it down and starting it again). Instead, it's re-reading its config file. I'd lay a bet that this is caused by your logrotation software. If logs are rotated by moving the log to a new name, and creating a new file with the old name, then you need to restart apache in order to make it begin using the ...


4

A server that has an uptime of 11 months is a server that is probably 11 months out-of-date with current security hotfixes (and other patches, updates and service packs). Having been up so long, I would highly recommend rebooting the system prior to installing any patches, so that if the machine does not boot up, then at least you know that it was not one of ...


4

I try to do a service window once a month. This is usually close enough to "patch release day" that I'm not too likely to get compromised, but far enough away that if there are going to be problems with the pending patches, some other sucker admin team gets to find them. When it comes to Windows servers, my patch plan always includes two or three reboots: ...


4

Apache will usually not crash or need to be restarted for most scenarios. Regular deaths suggest an issue with a module, configuration issue or resource problem. A good start would be the (error-) logs of apache, they usually reside in /var/log/apache or similar (see server config). Also, Apache 2.0.54 is quite outdated, you should update this as soon as ...



Only top voted, non community-wiki answers of a minimum length are eligible