| Previous | 14.1 Specifics of measurement server types | Next |
|---|
The WS-Man measurement server uses the Web Services Management protocol to do the measurements, although currently it only supports the Windows specific Windows Remote Management (WinRM) based measurements. This allows among others to use the Windows WMI provided services.
The equipment parameters are the following, their usage depends on the authentication used, see later:
· Host (WSMAN EQ 1 HOST): the name or the IP address of the monitored server. An IP address can only be used with the Basic authentication, in case of Kerberos the host name has to be used
· Protocol (WSMAN EQ 2 MODE): HTTP or HTTPS. In case of Kerberos the HTTP protocol is recommended (since the Kerberos protocol does the encryption itself), while the HTTPS is recommended in case of the Basic authentication.
· Port (WSMAN EQ 3 PORT): WinRM usually uses the port 5985 for HTTP and 5986 for HTTPS
· Authentication (WSMAN EQ 4 AUTH):
o Kerberos: this uses the Active Directory and it is based on domain. This mode is only supported when the collector is running on Red Hat / CentOS / Oracle Linux 6 or later!
· User name (WSMAN EQ 5 USER): the user must have specific rights on the monitored server, see later
· Password (WSMAN EQ 6 PWD): either the password must be provided in clear-text or a password file in the format of FILE:name_of_the_file, in which case it is recommended to use an absolute file path, for example: FILE:/opt/pvsr/username.pwd. The file is either a Kerberos specific key file or a simple file containing the password in clear-text in case of Basic authentication.
· Realm (WSMAN EQ 7 REALM): it is only used in case of Kerberos authentication, in which case it must be the realm specified in the Active Directory in upper-case format.
· OS version (Z 01 OS_VERSION): Non-modifiable automatically discovered parameter. It contains the operating system running on the server
· Product type (Z 02 PRODUCT_TYPE): Non-modifiable automatically discovered parameter. It contains the system product type
· CPU (Z 03 CPU): Non-modifiable automatically discovered parameter. It contains the CPU information for the server
- Memory (Z 03 MEMINFO): Memory information of the system. Non-modifiable automatically discovered parameter
- Swap (Z 03 SWAPINFO): Swap information of the system. Non-modifiable automatically discovered parameter
· IPv4 address(es) (Z 04 IPADDR): Non-modifiable automatically discovered parameter. It contains the IP addresses of the system
· Cluster (Z 05 CLUSTERNAME): Non-modifiable automatically discovered parameter. It contains the name of the cluster it belongs to (if it belongs to any cluster)
Important! When using WinRM from the command line then both the server and the client have to be configured. In the examples below only the server configuration is detailed, since for the data collector only the server part is relevant. However: one wants to test the settings using the winrm command, then the client side also has to be configured correctly.
In case of HTTPS protocol the application needs an additional Perl library called Crypt-SSLeay-0.58 which must be installed after the PVSR installation.
Generic Windows configuration
If the WinRM service is not running then it must be started first, its name is Windows Remote Management (WS-Management). It is recommended to set the starting of the service to Automatic. After the service is started the basic configuration can be done using the “winrm qc” command. Only administrators are allowed to use the WinRM.
Kerberos authentication with HTTP protocol
Windows side: The “winrm qc” command does the necessary configuration for Kerberos and HTTP with port 5985. If the command fails (for example if the server has an enabled public interface) then the configuration must be completed by hand. Typical configurations in such a case:
· Create a listener: winrm create winrm/config/listener?address=*+transport=http
· Enable the port 5985 on the Windows firewall
Kerberos authentication is enabled by default. This means a domain based authentication and while the protocol is HTTP, the communication is encrypted in the Kerberos layer itself.
Linux side (Red Hat / CentOS / Oracle Linux 6 or later): the Linux supports the Kerberos authentication by default, onlthe Linux supports the Kerberos authentication by default, only the /etc/krb5.conf file must be changed. It is important to note that whenever the file contains an uppercase value then it is required that the new value must be uppercase as well. Normally the lower- and uppercase EXAMPLE.COM values must be replaced in the config file, the yellow lines must be added and the kdc and admin_server values must be specified correctly. Sample configuration:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = NETVISOR.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tkt_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96, rc4-hmac
default_tgs_enctypes = aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96, rc4-hmac
[realms]
NETVISOR.LOCAL = {
kdc = nvpdc.netvisor.local
admin_server = nvpdc.netvisor.local
}
[domain_realm]
.netvisor.local = NETVISOR.LOCAL
netvisor.local = NETVISOR.LOCAL
The configuration can be tested by acquiring a Kerberos ticket and then list it:
[pvsr@localhost]$ kinit username@NETVISOR.LOCAL
Password for username@NETVISOR.LOCAL:
[pvsr@localhost]$ klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: username@NETVISOR.LOCAL
Valid starting Expires Service principal
02/17/12 16:25:37 02/18/12 02:25:41 krbtgt/NETVISOR.LOCAL@NETVISOR.LOCAL
renew until 02/18/12 16:25:37
The password file for PVSR can be created with the ktutil command. The command does not need to be ran by the PVSR OS user but it is recommended. It is also recommended to use an absolute file path (in case of a relative file path PVSR will look for the file in its bin directory). In case of Windows Server 2003 domain controller the value of the –e parameter must be RC4-HMAC, in case of Windows Server 2008 either AES128-CTS or AES265-CTS. A keytab file may contain multiple entries, in this case multiple addent commands must be used. An example case for this might be an installation with multiple domains, for example parent and child domains.
[pvsr@localhost]$ ktutil
ktutil: addent -password -p username@NETVISOR.LOCAL -k 3 -e RC4-HMAC
Password for username@NETVISOR.LOCAL:
ktutil: wkt /opt/pvsr/etc/kerberos.keytab
ktutil: exit
The PVSR OS user must have read rights on the created file. The Windows and the Linux PVSR user do not need to have any relationship whatsoever. After the configuration is done one can create the equipment in PVSR.
If we want to connect to a Windows machine in a trusted subdomain then the keytab file must contain both domains.
Figure 192. PVSR configuration with HTTP and Kerberos authentication
Basic authentication with HTTPS protocol
Windows side: The “winrm qc” command does not configure either the Basic authentication or the HTTPS protocol, so additional configurations are needed:
· winrm set winrm/config/Service/auth @{Basic="true"}
· winrm create winrm/config/Listener?Address=*+Transport=HTTPS
· Enable the port 5986 on the Windows firewall
PVSR side: PVSR does not contain a necessary Perl library for the HTTPS protocol, so it must be installed after the PVSR installation. Its name is Crypt-SSLeay-0.58. If one wants to use a password file then it must contain the password in clear-text format. It is recommended to use an absolute file path, otherwise PVSR will look for the file in the bin directory.
Figure 193. PVSR configuration with HTTPS and Basic authentication
Measurement definitions
The data collector supports a generic measurement expression format which can be used to get any kind of WMI parameter. There are four different variable definition formats:
· WQL_TABLE: it can be used in multiple-instances measurement types (where Table is set to Yes). It starts with the WQL_TABLE_ prefix then the WMI namespace then the | sign, the name of the object, the / sign, the name of the filter parameter (which identifies the object), the @ sign, the name of the measured parameter and in case of a measurement expression finally the .PORT part, which must not appear for the Description OID parameter. For example: WQL_TABLE_cimv2|Win32_LogicalDisk/Name@freespace.PORT
· WQL_*_TABLE: for the most part this is the same as WQL_TABLE, with one exception. In case of WQL_TABLE PVSR gathers together all the required parameters and only queries them (for example select Name, freespace from Win32_LogicalDisk). Sometimes on the server side this feature is not implemented, in which case PVSR has to query every parameter (select * from …). The WQL_*_TABLE can be used in these cases, for example: WQL_*_TABLE_MicrosoftExchangeV2|Exchange_Mailbox/MAILBOXDISPLAYNAME@Size.PORT
· WQL_INSTANCE: in case of WQL_TABLE PVSR gets all instances and does the filtering on its own. In some cases this can result in unnecessary traffic and processing in which case the WQL_INSTANCE format can be used. The format is the same as WQL_TABLE except it queries the instances one-by-one
· WQL_ROW: any kind of query can be implemented with this format, although only the first row (entry) will be processed. Its format: WQL_ROW_, then the WMI namespace, the | sign, the query and finally after the @ sign the needed measurement parameter name, for example: WQL_ROW_cimv2|select * from Win32_PageFileUsage@CurrentUsage
Currently three collector pages are supported by the WS-Man data collector: Windows events, Exchange mailbox and Custom select.
The page is automatically refreshed and it can be used to view the running processes. PVSR shows the main process parameters (process identifier, name, command) and statistics (since the last page refresh): CPU and memory usage and read-write operations:
Figure 194. Windows collector page: Processes
The CPU shows the cumulative user and kernel times, but the separate values can be viewed by clicking on the arrow icon: it then shows the values not just as percentage but also as seconds. 100% represents the total CPU usage on all cores, so if a single-threaded applications fully uses one core in a dual-core system then its CPU usage will be 50%. When the user clicks on the [Details] link then the same values are shown, but on charts:
Figure 195. Windows collector page: Process details
The page can be used to view the installed services on the monitored server. The page shows the main service parameters. If the service is currently running then by clicking on the [Details] link the detailed process page is shown.
Figure 196. Windows collector page: Services
The page can be used to query the events from the monitored Windows system for a specified time span. By default the page shows the events for the last 10 minutes, but no more than 500 events. These parameters can be changed and the page can be regenerated by clicking on the OK button. The received table can be filtered and ordered on the client side.
Figure 197. PVSR collector page: Windows events
This page is only available to administrator users. They can run any WQL select statement and PVSR shows the returned result set. The default namespace is CIMV2, but it can also be changed:
Figure 198. PVSR collector page: Custom select