|May the source be with you, but remember the KISS principle ;-)|
|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||HP Operations Center||Recommended Links||Unix System Monitoring||HP Operations Manager||SiteScope - Operations Manager integration||Event Correlation|
|Website monitoring||Web log analysis||Sample simple monitoring scripts||Syslog monitoring||History||Humor||Etc|
HP SiteScope is an acquired (and still not well integrated in HP product line) product which is sold now by HP as a part or Operations Center set of software. It was acquired from Mercury Interactive (the product initially was called Freshwater ; the company was acquired by Mercury Interactive which in turn was acquired by HP).
It provides simple agentless monitoring via telnet or SSH with a nice Web dashboard. Sitescope server can run on both in Windows and Unix. Looks more like a bastard child then a legitimate product in HP Operations Center product line as its host-based part of monitoring implicitly competes with Operations Manager agent-based monitoring and network based part competes with NNM.
Licensing costs are based on "per monitor" pricing scheme and for large number of monitors the product can be quite expensive, more expensive then HO Operations Manager. The price of the OMU agent is approximately $500 per node and with maintenance approximately 20% of this you need just ten Sitescope monitors (assuming it is $50 per monitor) on the server to exceed acquisition cost of the OMU agent. But OMU can do so much more then SiteScope. In this sense low cost tools line Nagios might be a better deal but the amount of adaptation it requires is larger. What is really important here is to create a matrix of the functionality you need. Each product does certain things very well. And some functionality, which might be important or unimportant to you can be weak or missing. But other things equal I recommend to start with an open source product as in this case you will have a frame of reference that will help you to understand strong and weak spots of Sitescope and you will be able to negotiate with HP much better. That also can help to avoid blunders with consultants, if the company uses them for deployment.
Also There is nothing in Sitescope technology wise that can't be (with some additional effort, there is no free lunch) replicated in Nagios and/or other free monitoring systems. So the selection is by-and-large optional and often more is related to political trends in particular organization then technical considerations.
SiteScope is called an agentless technology because it sends native UNIX commands/scripts (defined in /SiteScope/templates ) via telnet of SSH and collects output. First of all the term agentless in slightly misleading (in reality existing services i.e. telnet and SSH serve as an agent and create overhead). This approach has obvious limitations (time of running of the monitor should be pretty short one, less then interval between probes), problems with connection timeout, availability of the server, and so on.
Out of the box Sitescope can monitor almost many aspects of running Windows and UNIX systems (networks, server health, services health, databases, applications, etc.). Among prepackaged monitors:
The original developer, Colorado based Freshwater Software charged $2,495 for unlimited number of monitors. Mercury bought the company and the product in 2001 and changed licensing to $60 per unit which essentially killed the product(those greedy Israelites ;-) Simplifying one unit is equal one monitor, so the original price covered only 40 monitors. Total number of "units" you need is equal to the number of servers multiplied by the number of monitors on each machine. It you have a hundred server and use ten monitors on each acquisition cost is around 50K, which is close to the cost of OMU for the same infrastructure with the important different that in OMU the number of probes is unlimited and capabilities of product are much higher. In other words anybody who wants to license the product for more than a hundred servers should evaluate alternatives. For smaller installation and for very small number of monitor per server the product remains quite competitive and despite using Java (with Tomcat as an application server) the stability of recent versions is OK.
SiteScope can cause approximately 10% overhead (depending, of couse, on whether SSH or telnet connection is used as well as the number of monitors for a particular server) as responding to remote queries entail additional overhead especially if probes are very frequent (minimum is 15 seconds). Perhaps for this reason the SiteScope monitor has a default measurement period of 10 minutes. To change this
Measurement period should be enough for running most resource intensive probe in high load environment. That means that max time should one tenth of the measurement period or so.
April 23, 2008 | Altentee
In working with SiteScope of late, I’ve found that it doesn’t always collect performance metrics the way I want to. More importantly, it can often turn a simple monitoring activity into a complex disaster. Take monitoring via JMX for example. In SiteScope, it has a rather complicated (and sometimes broken) interface when trying to communicate with a busy MBean Server. One can quite easily roll your own JMX monitor using open source tools in about 65 lines of code as I demonstrated here.
But we still all use tools like LoadRunner in these commercial 9-5 contracts right? Wouldn’t it be nice, if you could roll your own custom monitors in Ruby, Perl or whatever language you like, store that data in a simple repository, let’s say a MySQL database, and still be able to hook into those metrics from a LoadRunner Controller during test execution!?
It is possible, with one PHP file and a simple WAMP (or LAMP) installation all wrapped up in a SiteScope-like alternative.
First thing, is you will probably want to get data from a variety of sources/platforms/operating systems. Using common scripting languages it is possible to roll your own remote agents.
For example, the following UDP server written in Perl, will listen on port 5151 in a central location, possibly on the same box as your SiteScope alternative.
I’ve also added some custom formatting templates for the type of remote monitors you might engage (vmstat, sar, iostat etc)
April 14, 2008 | LinkedIn
I'm presently in an environment where we use both SiteScope and Nagios. This is not because there is anything that one of them does that the other can't technically also do. It is simply an outgrowth of having two different teams with a vested interest in monitoring and alerting with totally different backgrounds and approaches. In our case it is a NOC that wanted a Windows-based SiteScope server and a Systems Operations group that already had a number of Linux-based Nagios servers.
I've dealt with both, though I'm considerably familiar with Nagios. We made a few attempts to migrate Nagios checks into SiteScope but found it somewhat awkward to make happen. Mostly this revolved around the fact that custom scripts for generating checks as new services were discovered depended on a number of tools that did not easily exist on the Windows platform (though Cygwin did eliminate some of that difficulty). Since SiteScope can be implemented on a Unix platform though, this could easily be a non-issue for other environments.
Even if we had been able to seamless migrate such scripts however, there doesn't seem to be much documentation on modifying SiteScope's configuration in a scripted way. I expect that had we been able to reach this hurdle we may well have stumbled.
I think this last point though is why I prefer Nagios to SiteScope. If I want to get fancy, I can dig into Nagios for myself and come up with a solution. With SiteScope, you're fine if you're doing something with the canned checks or features, but anything else gets cumbersome.
SiteScope does score over Nagios on the availability of well supported checks and solution sets. Nagios may well be able to perform the same checks with a plug-in, but the quality and supportability of Nagios plug-ins is somewhat hit or miss.
Then of course there is the price tag. Nagios is free, whereas Mercury charges (and quite a bit if you have a need for lots of monitoring points). Professional Nagios consulting and support is available though, so it doens't have to be a roll-your own sort of thing if you *are* willing to spend some money.
Because of its open nature, Nagios tends to integrate well with almost anything. The most recent releases have added a new feature called NDO (Nagios Data Out) which puts virtually anything you could want to know about your Nagios environment into an SQL database, including check results and configuration. This has facilitated quite a few interesting add-ons, including one called NagVis that allows graphical views to be created in almost any organizational structure you desire.
Mercury seems to stress the fact that SiteScope is 'agentless'. Personally, I feel this is misleading. It is true that you don't have to run an agent on clients to collect data and serve it up to your monitoring server. However it also means that most of the sorts of checks that you'd normally expect to be handled by an agent are instead handled by SiteScope logging into the box via SSH and running commands or scripts local to the box. In effect, sshd and a set of scripts become your agents. Given the choice, I prefer the well managed configuration of NRPE (Nagios Remote Plug-in Execution), which effectively allows the same capability without having to create a privileged service account for your SiteScope service (to my thinking, a huge security risk).
In summary, Nagios is not for the faint of heart. Its configuration is complex, but infinitely more manageable than that of SiteScope. With thought and planning, you can do some amazing things with it. The mixed blessing is that you can make custom solutions for almost anything. The downside to which is that you may have to do so if you can't find an existing solution.
SiteScope is actually quite nice, however. If your needs are well defined and unlikely to change much, then SiteScope could potentially be a smoother fit. It costs a good bit, but saves you time by working out of the box.
I use both currently. The big difference is nagios is infinitely more scriptable- you can easily create a combination of perl + snmp + nmap to generate the configs.
Another hit against sitescope is that if you have many checks, it misbehaves when doing confirmations and can cause backups and other grief. It also likes to lose it's brains and start throwing errors for no reason- where I work they ended up setting sitescope to restart once a day because around the 36 hour mark it started randomly failing checks until it was restarted.
I'm obviously biased towards Nagios, but I think it's also possible/feasible to use sitescope only for VuGen one-offs/walkthroughs and Nagios for everything else.
Matthew M.Paul S.
The great thing about Nagios is that it is a task scheduler and reporting tool. We use it to monitor all sorts of things including the usual disk-space and memory however with a bit of code (python in our case!) we've created a plugin to check the currently running version of Debian and alert us if a "dist-upgrade" is required.
If you can provide us with the data for anything that you want monitored (and that includes business processes such as number of sales calls made per day!), we can monitor it in Nagios and configure it to send you alerts.
Nagios is so much more than a Network Monitoring System - It rocks!
I have used Nagios and its predecessor Netsaint. Having the option to configure whatever check you might need - and yes, quite a few have been made to tailor the needs of the companies - there is little what I see as a con.
Configuration from ground up needs to be done no matter what package you select. However using template, it can be done - yes, requiring typing.
Dependencies, escalation models, host and service information, it's all in there.
On the other hand, when others need to configure Nagios also, it is handy to have the tooling available to 'click' your config in. Running Nagios with slave monitoring and failover, including the clickable config = opsview
Link included below - nagiosexchange already has been mentioned.
Jan 10, 2008 | IT Resource Center forums
I can only give you my opinion on SiteScope based on its comparison to Internet Services as I don't know anything about Nagios.
SiteScope is sharp and easy to use, install, ect. I would recommend using SiteScope for Website monitoring as well as other network testing I.E. DNS, DHCP etc. With that said, as for the agentless server monitoring, I've only set up 1 Unix and 1 Windows monitor. The Unix is very easy to do, and works well. As for the Windows side, well that was another story. In our environment NetBios is not acceptable, so I had to go with SSH. Which involves installing and setting up OpenSSH. After I learned how to use this product it was fairly easy to set up monitoring of CPU, Memory, and I am monitoring 1 application on a Windows Server. BUT, I couldn't imagine training all of our SA's to install OpenSSH on 500+ Windows servers, so the jury is still out on that one.
I recommend you read the specs on SiteScope and determine if it is the type of monitoring you are looking for. SiteScope does many different things which about only 10 of them will be used in our environment.
One other thing worth mentioning is web transactions.... They have a URL sequence tool available, but I've it difficult to use in situations where you have to add products to a cart and then attempt to check out. If you want to do those type of transactions, I recommend using VuGen and then buying the license to allow SiteScope to be able to read the type of scripts VuGen creates. Unless you want to also purchase BPM which Vugen and BPM are designed for each other. Confusing to say the least. But the URL sequencer is good if you want to test various hyperlinks or even forms to navigate through a sequence of webpages simulating what a user might do.
Anyhow that's all I can think of at this moment. Hope it is usefull.
May 15, 2006 | ReadList.com
We have a large SiteScope installation (we monitor several thousand servers with about 20 SiteScope machines) and are considering Nagios as a replacement. One of the issues we have is that we cannot, for various (mostly political) reasons, install an agent on the hosts we monitor.
We have successfully tested agentless monitoring by using Perl plugins that SSH to the remote host and run a command, parsing the output. However, we cannot run as many monitors per server as in our SiteScope
installation because of the latency incurred by setting up and breaking down the SSH connection for EACH monitor.
So my question is, does anyone know of a reasonable approach to agentless monitoring using Nagios? We are planning to try SSH4, which automatically keeps SSH connections open for later use, and forcing Nagios to run several scripts sequentlially against the same host. But this has the problem that a host which is down, or busy, could delay checking other hosts.
We would like, for many reasons (not just $$$, although that's a factor), to use Nagios, but having to install twice or three times as many servers to support it is out of the question. Any advice gratefully accepted.
Steve Keller (skeller)
Manager, Tools and ESM Group
Global Infrastructure Services
On Mon, May 15, 2006 at 03:34:53PM -0700, Keller, Steve wrote:
> a replacement. One of the issues we have is that we cannot, for various (mostly political) reasons, install an agent on the hosts we monitor.
By any chance is SNMP already in place on the target hosts? That might cut down on the number of agent-on-demand checks you have to run.
> So my question is, does anyone know of a reasonable approach to agentless monitoring using Nagios? We are planning to try SSH4, which
Check out FSH (http://freshmeat.net/projects/fsh/) which does a similiar thing. That should take care of the SSH overhead problem.
> this has the problem that a host which is down, or busy, could delay checking other hosts.
If you are writing this in perl, you can have your plugins timeout gracefully to prevent that. Nagios can be configured to time out plugins as well.
"Keyboard? How quaint!" - Scotty
This message is PGP/MIME signed.
Bringing up SNMP is a valid point (I'm currently handling ~25% of my active service checks this way). However there are a number of scenarios where the load on both the server/network/client is significantly greater to pull down a tree that needs processing (process table for instance), as the impact on the client is fairly large to process its own /proc entries to generate the values, pull them down sequentially, and parse the tree on the server. Same deal with a variety of network tables... Even Cisco/Foundry/etc do a horrible job of having their devices process & generate ARP tables, etc.
Even executing a remote command over SSH with the crypto overhead is faster in most situations (for me), and actually consumes less cycles on BOTH ends... This FSH project looks promising, though hasn't been updated since 2001... A scary prospect for anything that is crypto/authentication based :)
I don't see any reason we couldn't whip up an active check script that runs a number of commands sequentially over the SSH session that's set up at the beginning, applies the results as separate passive service checks. That's the only way I can think of to handle it, since each service check will otherwise be initiating a separate connection, at whatever rate is determined by its schedule in the queue.
Then again, check_by_fsh sounds nice too! Have to look at SSH4 features now
that you mentioned it Steve.
Just my thoughts.
John P. Rouillard
In message <C08F7254.27ECE%estair>,
Eli Stair writes:
>Even executing a remote command over SSH with the crypto overhead is faster
>in most situations (for me), and actually consumes less cycles on BOTH
>ends... This FSH project looks promising, though hasn't been updated since
>2001... A scary prospect for anything that is crypto/authentication based :)
Actually fsh is just a wrapper over ssh/rsh so it doesn't have any
security implications on it's own. It shares the security of the
>I don't see any reason we couldn't whip up an active check script that runs
>a number of commands sequentially over the SSH session that's set up at the
>beginning, applies the results as separate passive service checks. That's
>the only way I can think of to handle it, since each service check will
>otherwise be initiating a separate connection, at whatever rate is
>determined by its schedule in the queue.
check_by_ssh can run multiple commands in one shot and report each
output line to the proper service. See the -s flag and it's use with
multiple -C commands.
>Then again, check_by_fsh sounds nice too! Have to look at SSH4
>features now that you mentioned it Steve.
One problem is that you have to keep a master ssh connection
permanently open and mangage the connection if you aren't using
fsh. For a lot of hosts (1000+), this could put a resource strain on
the server as ports are taken up and 1000 ssh permanent ssh process
One thing that would also be nice for check_by_ssh would be the
ability to use an ssh_agent for the keys. Sadly the current
check_by_ssh sanitizes the environment a bit too well and removed the
environment variables used to allow ssh to communicate with it's
2009-12-29 | web3us.com
Sitescope is buggy not a good value (thread is from 01-18-2002 --NNB)
Pricing for SiteScope
Monitor Point Packs & Pricing:
SiteScope Monitoring Points Price Value per point
- 50 $3,750 $75
- 100 $6,000 $60
- 500 $25,000 $50
- 2000 $80,000 $40
Server monitor review
"Start where you are. Distant fields always look greener, but opportunity lies right where you are. Take advantage of every opportunity of service."
"If the grass is greener on the other side of the fence, you can bet the water bill is higher"
HP SiteScope - Wikipedia, the free encyclopedia
Original SiteScope® User Guide by Freshwater Software,
Mercury Sitescope User Guide Welcome to SiteScope (2004)
Mercury (formerly Mercury Interactive Corporation) is now part of Hewlett-Packard. The combination of Mercury Interactive and HP OpenView formed HP Software & Solutions, a global business unit within HP Enterprise Business. Mercury offered software for application management, application delivery, change and configuration management, service-oriented architecture, change request, quality assurance, and IT governance.
In 1989, Amnon Landan and Arye Finegold founded Mercury Interactive Corporation. The company was based in California and had offices located around the world. It also had a large R&D facility in Yehud, Israel.
The Mercury Interactive legacy products are now integrated and sold as part of the HP IT Management Software, also known as BTO (Business Technology Optimization), portfolio from HP's software division.
Mercury Interactive acquired Freshwater Software in 2001. The product is now called HP SiteScope software.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: July 07, 2013