Default services for a platform

[sjmh]

How does one add default services or servers that you want to be inventoried upon discovery of an agent?

For instance, say on each of our Linux systems, I want to monitor ntpd, sshd and say, xinetd.

I know I can edit the metric defaults and the alert defaults for these things, but I want Hyperic to add those service checks to the platform every time a new platform of that type is discovered.

So I install a new linux agent and it auto discovers. I want it to automatically start checking for certain services and servers, alot of which is isn't currently bothering to do.

Any suggestions on how to do this?

[sjmh]

This should be relatively easy to figure out - for instance, when I currently have a RHEL 5.0 system auto-discover, it finds a ProcessServer server resource.

When I inventory the system, it erases that ProcessServer resource and instead injects an sshd Process resource into the inventory for the system. How is it doing that and how can we add other processes that we want inventoried by default on the system?

[dougm_hyperic]

Hi Steven,

The system-plugin discovers the sshd process, see getSystemProcessValues():
http://svn.hyperic.org/trunk/plugins/system/src/org/hyperic/hq/plugin/system/ProcessorDetector.java?...
We could easily add checks for more of the standard services and/or make the list configurable via agent.properties.
Another option would be to use a plugin, there's an example for xinetd here which supports auto-discovery:
http://svn.hyperic.org/trunk/plugins/examples/xinetd-plugin.xml?revision=8547&root=Hyperic+HQ&view=m...
This plugin can be used a template for any daemon based process, just need to change the server name, PROC_QUERY and default log/conf files.

I know Travis suggested groovy/hqu automation in another thread, but if you'd prefer the agent-side/discovery route we can put together something using one of the above options. Longer term we could see about adding platform service creation policy style via the Administration section or elsewhere without having to touch the agent-side or having to manually sync when new platforms are added to the inventory.

[sjmh]

Thanks doug.

I've been watching all the HyperCAST's tonight and plugging through all the plugin documentation. It's been awhile and the documentation has improved since I last saw it.

At this time, honestly, I'd rather go the agent-side/discovery route. While I know my perl, python and php, I don't know java worth a squat, so to me the -plugin.xml files seem alot easier to write than groovy script and hashing over java docs and classes.

In the longer term, it'd be nice to see something via the Administration menu for configuring default platform service checks or heck, just giving a list of all processes from the process table when the agent first registers and allowing them to quickly designate any of them as processes they would like to create platform services for and automatically do that for them.

The automation of the groovy/hqu stuff seems like it's good for things such as what was needed in the other thread - quickly applying the same task over and over - but how well does groovy/hqu play into something like this - ie - setting defaults when servers register?

[staceyeschneide]

Jumping into the convo... but we have several large scale customers (like you) who are using it fairly extensively to update group inventory and/or configuration (using their config tool) as part of the provisioning process or to batch create a new set of checks when their protocols change. Its pretty powerful.

Check out some of the example scripts on the HyperFORGE. You *may* be surprised how easy the Groovy stuff is compared to real java.

[sjmh]

Hey Stacey,

It's not the Groovy that's too difficult - it's more the interfacing with partially documented java API's and having to browse the source to try and figure out what is going on. Are there any particular scripts you are referring to that I'm missing? I saw the HTTP Check snippet and the Mass plugin, but other then those I've haven't seen anything.

The HyperCASTs and flash demos are invaluable and I've been reading all the documentation on the HQU and Groovy apps ( and I have my Groovy in Action book, which Jon recommended ) - however, some stuff, especially the HQ backend API's are still somewhat undocumented - or at least - I couldn't find where they were documented at.

[Leander]

I would just like to say that I completely agree with everything shajducko is saying here

and in other threads (e.g.: here and here).


We've run into the _exact_ same problems whilst setting up our HQ environment.


My main gripe is that HQ appears is starting to show signs of featuritis,

but yet still lacks a number of basic features w.r.t. (ease of) administration,

usability and intuitiveness. Now, the HQU framework looks powerful and useful enough,

but many (most?) users are likely still missing out on its (significant) potential,

because the documentation is far from complete and lacks sufficient explanation for

users to grasp its workings. The docs offer little more than examples and code snippets

and there is no API specification (that I know of).


Another factor that adds to this is that the majority of HQ users are probably

"systems" type people like myself (as opposed to programmers), who don't mind whipping

up a quick script or a couple of lines of code to get something done, but who don't

generally use Java (or Groovy) on a regular basis. I do know my way around Java, but

currently the learning curve is just too steep to gain any real or immediate benefit

from HQU. I respect Hyperic's decision to commit to HQU and Groovy and I understand

that this should deliver a great amount of flexibility and power to HQ users now and in

the future. However, I wouldn't know how, because the examples just don't cut it...




In my opinion, HQ could benefit greatly in many areas if more time was spent on stabilising,

improving and documenting HQ's current state, before adding truckloads of new features

and frameworks. Some examples of what I'm talking about:

• 
  
• don't overwrite the global metric display range setting upon selecting a different range anywhere in the UI
  
• improving autodiscovery queue management.
  E.g.: "skipping" a discovered resource currently renders it completely
  inaccessible,
  with no way of getting it back without resorting to performing manual SQL queries
  
• consolidated/unified menus and navigation
  
• don't overwrite individual resource configuration when the metric template changes
  
• more product plugins (and documentation!)
  
• speed and performance improvement (UI, charts, database)
  
• agent platform IP address and hostname changes are currently a world of hurt
  
• better error/exception handling and logging:
  
  • 
    
  • Errors that occur in the UI often result in nasty stacktraces on the screen.
    
    
  • Plugin misconfiguration may results in misleading and/or incorrect errors.
    E.g.: I've seen plugins
    display (generic) error messages that were simply not true or even unrelated to the actual problem.
    
    
  • Errors in agent and server often result in literally dozens of lines of logged stack traces,
    
    with not so much as a clue to what is actually going wrong
    
• string based metric collection and alerting
  

Leander

[JohnMarkOrg]

Hi Leander,

As the community manager here, I just wanted to point out a couple of things. Some of your bullet points will need to be addressed by our product team - and I promise you that they will be shortly. For the stuff I can answer...

1. HQU is intended to make life easier for sysadmin types, by making data accessible to any scripting language that can grok curl, wget, or their equivalents. If you can make perl, python or php parse XML, then you can go very far with HQU plugins. You are correct that there needs to be more stuff added to be completely usable by sysadmins, and we are definitely working on that. The event center is just one example, and there are many more on the way. For the HQU plugins that have already been added, accessing the data returned by them is pretty easy - much easier than before.

2. Ironically, HQU will actually help to solve your point about consolidated menus and navigation

3. a new auto-discovery can be automatically kickstarted by removing the data directory from your agent. Not the most elegant solution, to be sure, but better than manual DB queries. Have you tried to manually perform an auto-discovery via the tools menu in the platform view?

4. We are definitely adding more product plugins as we go along. Do you have any specific requests?

5. speed and performance have improved dramatically, but I guess not fast enough?

We will make sure that these items are logged, but for some of them, more details would be good. I'm assuming you've logged those elsewhere? We do need detailed bug reports and feature requests.

As I mentioned, our product manager will be stopping by, but I wanted to respond to you in the meantime. This sort of information and feedback is crucial, and we thrive on it. Thank you for taking the time to write it up.

Thanks!
John Mark

[jtravis_hyperic]

Hey Stephen,

HQU is a new venture for us. One of the main goals is to provide APIs that non-programmers can use. Clearly we're a long way from that goal .. a long way.

One thing that we are doing is trying to be very attentive to requests from the community wrt filling out the HQU APIs and providing examples.

The best way to get what you're after is probably to voice what you're trying to do in the forums and hopefully we'll be able to whip up a small groovy to do what you need. That pushes us to get the APIs documented and provides more examples that the community can build on.

-- Jon

[squinn_hyperic]

If you are looking for the HQU Groovy API you can check here: http://support.hyperic.com/confluence/display/hypcomm/HQU+Groovy+API