ok guys this is freaking me out.

I did some more experimenting.

I tried setting 'Host Name' to ${dev/id}, to ${dev/manageIp}, to 'www.ignore.me' and I tried emptying it.

All of them result in Zenoss doing an http request with "Host: QA:12080", resulting a reply of "400 Bad Request"

To be sure I didn't mix up the roles of the hostname and ip I tried setting the hostname to ${dev/manageIp} and the ip to 'www.ignore.me'.

but this gave the same problem.

So wtf?

Thanks for your reply Nick.

Here are my settings:

Hostname:'QA MQ-XDF server' (class: 'Comat-MQ-XDF')

on that server (in that class) I have the following performance template:

Name:          xdf_http_croppingtool_12080

Source type: HttpMonitor

Enabled:       true

Component:

Event Class:  /Status/Web

Event Key:

Severity:        Warning

Timeout:        60

Cycle Time:   300

Host Name:   ${dev/id}

IP Address:   ${dev/manageIp}

Port:             12080

Use SSL:       no

Url:                / (I also tried: http://${dev/manageIp}/, same result )

Regular Expression:

Case Sensitive: no

Invert Expression: no

Basic Auth User:

Basic Auth Password:

Redirect Behavior: follow

So what I expect is that Zenoss does a http request to path '/' on port 12080 on this server.

However, this is this the http request and response I get:

GET / HTTP/1.0
User-Agent: check_http/v2053 (nagios-plugins 1.4.13)
Connection: close
Host: QA:12080

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Date: Mon, 21 Sep 2009 15:28:38 GMT
Connection: close

As you can see, the value in the 'Host' field is totally messed up. It seems like Zenoss takes the first "word" (until first whitespace) of the hostname and then puts ':<port>' behind it. And no matter what I configure in the settings, I keep getting this (see my earlier posts).

In the tutorial you mentioned you make a new device for each website, with as devicename the hostname of the website, so in cases like those there is no need to explicitly configure the hostname and you are not affected by this bug.

In my case, sites are coupled to an ip (server). it makes more sense to do the monitoring on the server directly, so that when the ip changes, the server is taken offline, etc i can change things in 1 place.  I find it weird to make a new device for this.