The HTTP POST request contains event information in JSON format. Oracle Traffic Director supports notifications for the following two events:
Learn about how Oracle Traffic Director sends notifications to configured HTTP endpoint URL when it detects a change in the origin server status.
The origin server status change event is said to occur when one of the two events occur:
OTD marks the origin server as offline.
OTD marks the origin server back as online from offline.
A notification message is sent when there is a status change of any origin server that is part of the configuration. You cannot receive notifications for a particular origin server of interest while subscribing to the notifications.
Multiple notifications can be sent when there is a change in the status of an origin server that is part of multiple origin server pools or multiple Oracle Traffic Director instances.
Log in to Fusion Middleware Control for Traffic Director, as described in Graphical User Interface-Fusion Middleware Control.
Click the WebLogic Domain button at the upper left (or) right corner of the page.
Select Administration > OTD Configurations.
A list of available OTD Configurations is displayed.
Select a configuration for which Event Subscriptions will be enabled.
Select Configuration > Advanced Configuration > Event Subscriptions.
The Events Subscriptions page is displayed.
In the Common Tasks pane, click Create under Event Subscription.
The New Event Subscription wizard opens.
Follow the on-screen prompts to complete the creation of the Event Subscription by using the details- Name of the subscription, URL, and so on - that you decided earlier.
Click OK on the Results screen.
After the Event Subscription is created, the Results screen of the New Event Subscription wizard displays a message confirming the successful creation of the Event Subscription.
Creating an event subscription
To create an event subscription, run the otd_createEventSubscription command, as shown in the example.
props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
props['url'] = 'http://example.com:7777/subscriber'
otd_createEventSubscription(props)
The first command subscribes to the URL: http://example.com:7777/subscriber
Viewing a list of event subscriptions
To view a list of subscribed event subscriptions, run the otd_listEventSubscriptions command.
For example, to display the event subscriptions scheduled for instances of the configuration:
props = {}
props['configuration'] = 'foo'
otd_listEventSubscriptions(props)
Deleting an event subscription
To delete an event subscription, run the otd_deleteEventSubscription command, as shown in the example.
props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
otd_deleteEventSubscription(props)
Setting an event subscription properties
When you create an event subscription, it is enabled automatically.
The command otd_setEventSubscriptionProperties with 'enabled' as 'false' can be used to disable event subscriptions.
To disable an event, set the enabled property to false.
props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
props['enabled'] = 'true'
otd_setEventSubscriptionProperties(props)
Getting an event subscription properties
The command otd_getEventSubscriptionProperties with 'enabled' as 'true' must be used to get the event subscription properties.
To enable an event, set the enabled property to true:
props = {}
props['configuration'] = 'foo'
props['event-subscription'] = 'bar'
otd_getEventSubscriptionProperties(props)
To know the details of the command and its each parameter/option, use help, as shown below:
help('otd_createEventSubscription')
When a notification to a subscribed URL is sent, the Content-type header value is set to application/json. When an event occurs, the OTD sends HTTP POST to the endpoint with a message body that contains a JSON document with the name/value pairs as described in this section.
Table 14-1 JSON properties common to all events
| JSON property | Description |
|---|---|
|
event-type |
Type of the event. Value: |
|
domain-name |
Name of the domain where Oracle Traffic Director instance is configured. |
|
instance-name |
Name of the Oracle Traffic Director instance. |
|
timestamp |
The time when the event occurred and detected by OTD. |
Table 14-2 JSON property specific to origin-server-status-change event
| JSON property | Description |
|---|---|
|
pool-name |
Origin server pool name to which the origin server is associated with. |
|
host |
Origin server host for which the status being sent. |
|
port |
Origin server port. |
|
status |
Online or offline. |
|
reason |
Reason for Oracle Traffic Director marking the origin server as offline or online. |
|
protocol |
Health check protocol used. |
{
"$schema":"http://json-schema.org/draft-04/schema#",
"id":"",
"type":"object",
"properties":{
"v1.0":{
"id":"/v1.0",
"type":"object",
"properties":{
"event-type":{
"id":"/v1.0/event-type",
"type":"string"
},
"domain-name":{
"id":"/v1.0/domain-name",
"type":"string"
},
"instance-name":{
"id":"/v1.0/instance-name",
"type":"string"
},
"origin-server":{
"id":"/v1.0/origin-server",
"type":"object",
"properties":{
"pool-name":{
"id":"/v1.0/origin-server/pool-name",
"type":"string"
},
"host":{
"id":"/v1.0/origin-server/host",
"type":"string"
},
"port":{
"id":"/v1.0/origin-server/port",
"type":"integer"
},
"health-check":{
"id":"/v1.0/origin-server/health-check",
"type":"object",
"properties":{
"protocol":{
"id":"/v1.0/origin-server/health-check/protocol",
"type":"string"
},
"status":{
"id":"/v1.0/origin-server/health-check/status",
"type":"string"
},
"reason":{
"id":"/v1.0/origin-server/health-check/reason",
"type":"string"
}
},
"required":[
"status"
]
}
},
"required":[
"host",
"port",
"health-check"
]
},
"timestamp":{
"id":"/v1.0/timestamp",
"type":"string"
}
},
"required":[
"event-type",
"domain-name",
"instance-name",
"origin-server",
"timestamp"
]
}
},
"required":[
"v1.0"
]
}
Content-Type: application/json
Content:
{
"v1.0":{
"event-type":"origin-server-status-change",
"domain-name":"base_domain",
"instance-name":"otd1",
"origin-server":{
"pool-name":"testpool",
"host":"slc06cdz",
"port":7777,
"health-check":{
"protocol":"HTTP",
"status":"offline",
"reason":"Server not reachable"
}
},
"timestamp":"Mon, 18 Apr 2016 04:34:23 -07:00"
}
}
When a subscriber responds with an error code, Oracle Traffic Director:
Logs the following warning message to the server log:
Event Dispatcher: response code <http_response_code> received from subscriber <subscription_url>
Event Dispatcher: unable to post event <json_notification_data> to subscriber <subscription_url>
Discards the event.
When a subscriber is not reachable, Oracle Traffic Director:
Tries re posting the event three times
Logs the following warning message to the server log:
Event Dispatcher: unable to receive response from subscriber <subscription_url>
Event Dispatcher: unable to post event <json_notification_data> to subscriber <subscription_url>
Discards the event.
A request limit exceeded event occurs when a request limit configured for a virtual server is exceeded. OTD checks if a request limit was exceeded in the specified interval of time, event-notification-interval and sends a notification message to the configured HTTP endpoint.
The event-notification-interval is a configurable parameter set by the user for a request limit, while subscribing to notifications from it. A notification message is sent for every request limit that exceeds the configured request limit. A request limit is identified using the name provided while configuring the request limit.
If the request limit uses the monitor attribute to monitor requests, the notification message will contain a JSON array of all monitors that exceeded the thresholds.
When the virtual server exceeds the specified request limit, OTD rejects all subsequent requests that match the monitor attribute. The notification message will include information on the number of requests rejected for each monitor.
Note:
When a request limit is exceeded, OTD does not send a notification immediately.
When there is a high burst of traffic, request limit may exceed multiple times at close intervals of time. If OTD sends a notification message every time the request limit exceeds, there would be many notification messages. To avoid this, OTD checks if a request limit was exceeded in an interval of time and sends a notification message if it detects that the limit was exceeded.
Create an event subscription. See Subscribing to origin server status change event Using WLST.
Enabling request limit exceeded event
To enable events for a specified request limit, run the otd_enableRequestLimitEvents command, as shown in the example.
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['event-notification-interval'] = '60'
otd_enableRequestLimitEvents(props)
Disabling request limit exceeded event
To disable events for a specified request limit, run the otd_disableRequestLimitEvents command, as shown in the example.
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
otd_disableRequestLimitEvents(props)
Viewing request limit exceeded event properties
To view the properties of a specified request limit, run the otd_getRequestLimitProperties command.
POST messages sent to the endpoint has a message body that contains a JSON document with the name/value pairs described in this section.
Table 14-3 JSON properties common to all events
| JSON property | Description |
|---|---|
|
event-type |
Type of the event. Value: |
|
domain-name |
Name of the domain where Oracle Traffic Director instance is configured. |
|
instance-name |
Name of the Oracle Traffic Director instance. |
Table 14-4 JSON properties specific to notifications from request-limit-exceeded
| JSON property | Description |
|---|---|
|
time-begin |
Timestamp that indicates the begin of the event notification interval. |
|
time-end |
Timestamp that indicates the end of the event notification interval. |
|
virtual-server |
Name of the virtual server for which request-limiting is enabled. |
|
request-limit-rule |
Identifies the request limit rule that generated this notification message. |
|
monitor |
Value of the request attribute that is being monitored. For example, if monitor=$ip is specified in the -request-limit rule, the JSON property If the monitor is not specified in the request-limit rule, this property will be set to |
|
total-queue-overflows |
Total requests rejected due to queue overflow. |
|
total-queue-timeouts |
Total requests rejected due to timeout while waiting in the queue. |
{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "/",
"type": "object",
"properties": {
"v1.0": {
"id": "v1.0",
"type": "object",
"properties": {
"event-type": {
"id": "event-type",
"type": "string"
},
"domain-name": {
"id": "domain-name",
"type": "string"
},
"instance-name": {
"id": "instance-name",
"type": "string"
},
"event-notification-interval": {
"id": "event-notification-interval",
"type": "object",
"properties": {
"time-begin": {
"id": "time-begin",
"type": "string"
},
"time-end": {
"id": "time-end",
"type": "string"
}
}
},
"virtual-server": {
"id": "virtual-server",
"type": "string"
},
"request-limit-rule": {
"id": "request-limit-rule",
"type": "string"
},
"monitors": {
"id": "monitors",
"type": "array",
"items": {
"id": "0",
"type": "object",
"properties": {
"monitor": {
"id": "monitor",
"type": "string"
},
"total-rejects": {
"id": "total-rejects",
"type": "object",
"properties": {
"total-queue-overflows": {
"id": "total-queue-overflows",
"type": "integer"
},
"total-queue-timeouts": {
"id": "total-queue-timeouts",
"type": "integer"
}
}
}
}
}
}
},
"required": [
"event-type",
"domain-name",
"instance-name",
"event-notification-interval",
"virtual-server",
"request-limit-rule",
"monitors"
]
}
},
"required": [
"v1.0"
]
}
{
"v1.0": {
"event-type": "request-limit-exceeded",
"domain-name": "base domain",
"instance-name": "otd1",
"event-notification-interval": {
"time-begin": "Mon, 18 Apr 2016 04:34:23 -07:00",
"time-end": "Mon, 18 Apr 2016 04:35:23 -07:00"
},
"virtual-server": "1.example.com",
"request-limit-rule": "request-limit-1",
"monitors": [
{
"monitor": "16.181.76.89",
"total-rejects": {
"total-queue-overflows": 2,
"total-queue-timeouts": 3
}
}
]
}
}