|
In addition to the standard direct (TCP based) monitoring capabilities, a Talon XVM can be configured to allow administrative applications to monitor and manage it over messaging. |
nv.discovery.descriptor=<discovery-provider> nv.server.admin.transports=sma nv.server.admin.bus.descriptor=<bus-connection-decriptor> |
As long as both the admin client and the XVM are using the same discovery descriptor and message bus, they will be able to communicate with one another.
When enabling Admin over SMA it is important to note that by default admin clients using SMA will attempt to connect to discovered XVMs. If older version XVMs or XVMs not configured for Admin over SMA are advertising themselves over the admin client's discovery address the XVM will never respond and the admin client will see connection timeouts. To avoid this you may:
|
Admin Channels
The table below lists the bus channels used for administration over SMA:
| Name | Key | QOS | ID | Description |
|---|---|---|---|---|
| Command and Control | ||||
| xvm-request | xvm-admin/${xvmName}/request | BestEffort | 30000 | Command and control requests. |
| xvm-response | xvm-admin/${adminClientId}/response | BestEffort | 30001 | Command and control responses (to issuing admin client) |
| Monitoring | ||||
| xvm-heartbeat | xvm-admin/${xvmName}/heartbeat | BestEffort | 30003 | XVM heartbeats. |
| xvm-trace | xvm-admin/${xvmName}/trace | BestEffort | 30004 | Log trace records. |
| xvm-event | xvm-admin/${xvmName}/event | BestEffort | 30005 | Lifecycle and alert events. |
By default, all admin channels start with xvm-admin channel prefix. This prefix can be changed by setting the environment property nv.admin.sma.channelKeyPrefix which can be useful for cases where it is desirable to more granularly partition admin traffic. Note that each channel is configured with a topic level of either xvmName or adminClientId ... The xvmName topic level allows clients to listen in to a particular xvm, and the adminClientId, allows an XVM to send responses targeted to a particular adminClient.
When command and control is enabled, these channels allow admin clients to issue commands to an XVM. Such commands include XVM control commands such as triggering thread dumps or reloading applications and also include invocation of application-defined commands.
Requests and Response messages for command and control can be found in the com.neeve.server.mon.cnc package. At present, support for usage of command and control is reserved for the platform's admin APIs (Robin and Lumino).
XVM heartbeats are periodically emitted over the heartbeats channel when they are enabled for the XVM.
Heartbeats are emitted using the SrvMonHeartbeatMessage type defined in the com.neeve.server.mon package. While this package contains additional lifecycle related messages types used by direct monitoring clients, only SrvMonHeartbeatMessage are emitted over the heartbeats channel.
When enabled, SrvMonTraceRecords are emitted over the trace channel allowing admin clients to view trace output as it happens.
Tracer records are emitted using SrvMonTraceRecord message type that can be found in the com.neeve.server.mon.cnc package.
The events channel is used to emit events such as lifecycle or alert events which are defined in the com.neeve.server.mon.lifecycle and com.neeve.server.mon.alert.
Admin clients should not attempt to issue commands until an XVM has been discovered via the discovery provider (see Understanding Discovery). When an admin client detects that an XVM is no longer discoverable it should stop issuing commands over SMA.
Tools such as Robin, Lumino or the AdminTool must be configured to enable SMA as a transport along with the admin bus connection information. As admin clients won't always be configured via DDL, configuration is done via system/environment properties to configure connectivity to the XVMs monitoring server.
nv.server.admin.transports=sma nv.server.admin.sma.bus.descriptor=solace://solhost:55555&topic_starts_with_channel=false&SESSION_VPN_NAME=default&use_default_queue_name=false&use_default_queue_name_as_default_client_id=true&topic_starts_with_channel=false&usejni=true&single_session=true |
Alternatively, it is possible to configure the bus descriptor in decomposed form, which can be useful in cases where configuration properties are more overridden across environments.
nv.server.admin.transports=sma nv.server.admin.sma.bus.provider=solace nv.server.admin.sma.bus.address=solhost nv.server.admin.sma.bus.port=55555 nv.server.admin.sma.bus.properties.SESSION_VPN_NAME=default nv.server.admin.sma.bus.properties.use_default_queue_name=false nv.server.admin.sma.bus.properties.use_default_queue_name_as_default_client_id nv.server.admin.sma.bus.properties.topic_starts_with_channel=false nv.server.admin.sma.bus.properties.usejni=true nv.server.admin.sma.bus.properties.single_session=true |
XVMs can be configured using the same environment properties as clients by setting the properties in the DDL environment section:
<env>
<nv>
<server>
<admin>
<transports>sma</transports>
<sma>
<bus>
<descriptor>solace://solhost:55555&topic_starts_with_channel=false&SESSION_VPN_NAME=default&use_default_queue_name=false&use_default_queue_name_as_default_client_id=true&topic_starts_with_channel=false&usejni=true&single_session=true</bus>
</bus>
</sma>
</admin>
<server>
</nv>
</env> |
If you are using Robin or Lumino to provision your XVMs, setting up the admin transports in your config.xml is typically not necessary – robin will add the configuration in automatically based on the client settings configured in its robin.conf.
|
Using environment based configuration is the simplest way of configuring Admin over SMA for an XVM. In cases where bus configuration is not being injected by Robin or Lumino during deployment, it is possible to use the <xvm> <admin> element in DDL to enable admin over SMA and reference a DDL defined bus definition.
To configure an XVM to use a bus named 'xvm-admin' the XVM's <admin> <sma> element can be used:
<xvms>
<xvm name="order-processing-1" template="xvm-template">
<admin>
<transports>
<sma enabled="true">
<busName>xvm-admin</busName>
</sma>
</transports>
</admin>
<heartbeats enabled="true" interval="5s"/>
</xvm>
</xvms> |
The following bus definition can then be configured for use by the XVM.
<buses>
<bus name="xvm-admin">
<provider>solace</provider>
<address>solhost</address>
<port>55555</port>
</bus>
</buses> |
Admin channels (xvm-request, xvm-response, xvm-heartbeat, xvm-event, and xvm-trace) should not be configured for the bus, they are automatically created by the XVM when it is started.
With the above configuration, the order-processing-1 xvm will create a connection to solace://solhost:55555 with a username of order-processing-1. It will use the following topics:
Subscribe:
Publish:
Enabling xvm heartbeats isn't strictly necessary, but in most monitoring scenarios it is desirable. |
It is possible to use Admin over SMA in a purely passive monitoring capacity by setting the property:
nv.server.admin.passivemonitoringonly=true |
With the above configuration setting clients will throw an exception if an attempt is made to send commands to an XVM, and XVMs will not issue subscriptions on the xvm-request channel.
It is important, however, to ensure that your application packages the appropriate messaging provider jars.