Some details about .system trigger listener, other minor edits.

This commit is contained in:
Andrzej Bialecki 2017-10-12 11:56:47 +02:00
parent bac4049317
commit d8c132129e
2 changed files with 20 additions and 3 deletions

View File

@ -95,7 +95,12 @@ below, together with their configuration parameters.
This trigger listener sends trigger events and processing context as documents for indexing in
SolrCloud `.system` collection.
When a trigger configuration is first created a corresponding trigger listener configuration that
uses `SystemLogListener` is also automatically created, to make sure that all events and
actions related to the autoscaling framework are logged to the `.system` collection.
Supported configuration properties:
* `collection` - (string, optional) specifies the target collection where documents are sent.
Default value is `.system`
* `enabled` - (boolean, optional) enables the listener when true. Default value is true.
@ -128,6 +133,18 @@ processed)
`_s` or `_ss` suffix depending on whether the property value is a collection (values inside collection are treated as
strings, there's no recursive flattening)
The following configuration is used for the automatically created listener (in this case for a
trigger named `foo`):
[source,json]
----
{
'name' : 'foo.system',
'trigger' : 'solr.SystemLogListener',
'stage' : ['WAITING', 'STARTED', 'ABORTED', 'SUCCEEDED', 'FAILED', 'BEFORE_ACTION', 'AFTER_ACTION']
}
----
=== `HttpTriggerListener`
This listener uses HTTP POST to send a representation of event and context to a specified URL.
URL, payload and headers may contain property substitution patterns, which are then replaced with values takes from the

View File

@ -85,13 +85,13 @@ Now that we have an idea about how cluster management operations use policy and
The `autoAddReplicas` parameter passed to the create collection API in the quickstart section automatically creates a trigger that watches for a node going away. When the trigger fires, it computes and executes a plan to move all replicas hosted by the lost node to new nodes in the cluster. The target nodes are chosen based on the policy and preferences.
You can learn more about Triggers in the __TODO__ section.
You can learn more about Triggers in the section <<solrcloud-autoscaling-triggers.adoc,AutoScaling Triggers>>.
== Listeners
An AutoScaling *Listener* is attached to a trigger. Solr calls the listener each time the trigger fires as well as before and after the actions performed by the trigger. Listeners are useful as a call back mechanism to perform tasks such as logging or informing external systems about events. For example, a listener is automatically added by Solr to each Trigger to log details of the trigger fire and actions to the `.system` collection.
An AutoScaling *Listener* can be attached to a trigger. Solr calls the listener each time the trigger fires as well as before and after the actions performed by the trigger. Listeners are useful as a call back mechanism to perform tasks such as logging or informing external systems about events. For example, a listener is automatically added by Solr to each Trigger to log details of the trigger fire and actions to the `.system` collection.
You can learn more about Listeners in the __TODO__ section.
You can learn more about Listeners in the section <<solrcloud-autoscaling-policy-preferences.adoc,AutoScaling Listeners>>.
== Autoscaling APIs