The http input allows to let any http interface be the input for a watch.
The http input can be configured with the following options:
* `method` - Optional http method. (default to GET)
* `host` - The host of the http service.
* `port` - The port of the http service.
* `path` - The url path.
* `params` - Optional url query string options.
* `header` - Optional http header.
* `auth` - Optional authentication http heads.
* `body` - Optional body
The response of the http request is expected to be valid json.
Closeselastic/elasticsearch#157
Original commit: elastic/x-pack-elasticsearch@0b1f122615
Today every `watch` is associated with a `schedule`. When the watch is added to the system, its schedule is registered with the `scheduler` that is responsible to trigger the watch based on the schedule. This is effectively time based triggering of a `watch`.
Thinking about it further, triggering a watch is a higher abstraction than the schedule. Many things can potentially trigger a watch - a schedule (or time based triggering) is just one example of such trigger.
A `Trigger` was added to provide this abstraction. A `watch` is associated with a `trigger` not with a `schedule` directly. One type of `trigger` that can be set on a watch is a `schedule`.
This abstraction will enable us much flexibility in the future as we'll be able to add other types of triggers that are not necessarily based on time. 3 examples:
- we're planning to have a API that executes triggers on demand (rather than waiting for them to be triggered "naturally"). We could have a `"passive"` trigger with the intention to have a watch that can only be executed on demand. Today (with schedule only) you can achieve this by setting a `cron` schedule that is set to trigger very far in the future - but it's a hack.
- In the future we plan to have changes API in elasticsearch. An interesting trigger that we might want to add is `"changes"` - an ESP (event-stream processing) trigger that listens to all (data) events in the changes API, processes them and using some sort of state machine decides to trigger a watch based on some condition.
- With Shield we have audit trails. currently the only audit trail that is supported is log based (access logs). Another audit trail we'll add soon will be index based (indexing the audit info to elasticsearch). In the future, we might want to have `watcher` extend shield and add a `"watcher"` audit trail. this will effectively be a `"audit"` trigger that will trigger watches based on events arriving in the audit trail (think about notifying at real-time about a potential DDoS attack)
To support this change, we needed to change existing and introduce new constructs:
- A `Trigger` defines the logic of when a watch should be triggered
- A `TriggerEngine` is responsible for executing the logic defined by the `Trigger`
- A `TriggerEvent` is created whenever the engine triggers the trigger. The event holds relevant information (may be different for every trigger depending on its type and nature).
- A `TriggerService` manages trigger engines.
We currently have a single engine implementation - a `"scheduler"` trigger
- `ScheduleTrigger` defines a clock/calendar based schedule on which a watch should be triggered
- `QuartzScheduleEngine` a trigger engine that runs quartz scheduler which triggers the registered schedules.
- `ScheduleTriggerEvent` holds the `triggered_time` (the time the trigger was actually triggered) and the `scheduled_time` (the time the trigger was scheduled to trigger)
- Updated the docs
Closeselastic/elasticsearch#158
Original commit: elastic/x-pack-elasticsearch@5be20917cc
- Change action names to be aligned with Shield. All actions are categorized as `cluster management`.. the read actions (get & stats) are also also categorized as `cluster monitoring`.
- Added `ShieldIntegration` and `WatcherShieldModule` to handle all the integration points.
- We have a new internal shield user `__watcher_user` that will be the actor behind all the watcher interal action executions (managing the `.watches` and `.watch_history` indices
- This integration revealed a bug where the watcher plugin would not wire correctly with transport clients. This is now fixed with the introduction of a dedicated `TransportClientWatcherModule`
- Added docs
Closeselastic/elasticsearch#43
Original commit: elastic/x-pack-elasticsearch@26e9b0da06
Adds randomization.yml file that contains the versions of elasticsearch
and lucene to test the current branch against. This allows us to control
the versions we test against in the repo vs having to continually modify
the randomization scripts.
Closeselastic/elasticsearch#773
Original commit: elastic/x-pack-elasticsearch@5e5645a627
- Added an option for other plugins to define reserved roles. These roles will be reserved for the plugins and will be used by the plugin when executing actions. The reserved roles cannot be overridden by the `roles.yml` file. While at it, also made sure the system role cannot be defined in the `roles.yml` file. The roles can be registered via the `AuthorizationModule.registerReservedRole` method.
- Enable plugins to add their own (new) cluster & index privileges. The can be done by simply calling `Cluster.addCustom` and `Index.addCustom` static methods.
Original commit: elastic/x-pack-elasticsearch@11f795bebd
The timeout test times an operation that involves much more than a simple
socket connect. There is overheard from the UnboundID library and its
asynchronous nature that could cause delay in a response. This removes
the assertion that the call to session took less than one second and adds
an assertion about the exceptions cause.
Closeselastic/elasticsearch#740
Original commit: elastic/x-pack-elasticsearch@45577626b6
- `alerts` package is now `watcher` package
- we no longer use the term `Alert`, but instead we use `Watch`
- documentation still needs to be updated
Original commit: elastic/x-pack-elasticsearch@1225edf7e3
- Introduced `ssha256` hashing (salted sha-256) which is now the default in-mem hashing algorithm (instead of bcrypt4)
- changed the `md5` to be a real MD5 algorithm (used to be md5crypt.
- introduced `apr1` hashing algo. which is the old md5crypt algorithm.
Also updated the relevant docs & tests
Original commit: elastic/x-pack-elasticsearch@c8c0be5b95
SearchInput tests were failing locally for me in DEBUG because they weren't setting a valid alert on the ExecutionContext which was causing
the debug log messages in the SearchInput.execute method to NPE. I've added a dummy Alert to the context to fix things.
`
Original commit: elastic/x-pack-elasticsearch@2d744fdb7b
Also:
- removed `throttle` file (throttling is not covered in `alert-anatomy` page)
- fixed ctx model parameters in templates/scripts to use the `ctx` prefix.
- added a dediated section in alert-anatomy about execution context as template/script model
- wrote first page of `transform` section
Original commit: elastic/x-pack-elasticsearch@471ca7f0d9
Changed ClientProxy to be return responses instead of ActionFutures and removed builders. This helps with mocking.
Original commit: elastic/x-pack-elasticsearch@bfc36d9405
Enables filtering out sensitive settings from the nodes info API rest endpoint. Also provide a mechanism to filter out additional settings via a new `shield.hide_settings` setting.
Original commit: elastic/x-pack-elasticsearch@9bab5049e7
On Windows, ensureGreen times out due to some shards not being initialized so
this increases allocation logging.
Original commit: elastic/x-pack-elasticsearch@e3777a8e89
After the switch from elasticsearch.com to elastic.co, these tests started failing
due to socket connect errors. Now we will just connect to the OpenLDAP server
which should be a different machines than the ones running tests.
Original commit: elastic/x-pack-elasticsearch@7bf713a313
The idea behind a time warp mode is that while it's enabled the time related constructs in the alerts module are replaced with a mock test friendly version.. so we'll be able to control time and therefore avoid sleeping the threads.
In time warp mode:
- The `SchedulerMock` is used to manually fire jobs
- The `ClockMock` is used to set and fast forward time
- The alerts are executed on the same thread as the scheduler mock... so we don't have to deal with async nature at all. This is accomplished by the added `AlertsExecutor` abstraction.
By default, the time warp mode is enabled and tests run in it. If a test must not use the time warp mode, it is possible to add `@TimeWarped(false)` annotation to the test and it will then run with the standard scheduler & clock. It is also possible to disable this mode all together by running the tests with `-Dtests.timewarp=false`.
All the updated tests now work in both modes (whether the time warp mode is dis/enabled). This is important as on the server we would like to run the tests outside of this mode as well, but locally we'd like to run them with time warped enabled (so they'll be faster)
Also, cleaned up the tests.. we now only do `assertThat(...)` calls (no `assertTrue` or `assertEquals`... for consistency sake)
Original commit: elastic/x-pack-elasticsearch@11e09f6dea
The resolved anonymous user was not added to the REST request context. This resulted in that when the request was "translated" to a transport request, the fallback was the `system user`. The commit fixes that.
Original commit: elastic/x-pack-elasticsearch@acea6becf1
Any exception caught during authentication is only logged if DEBUG is enabled.
This changes the behavior to log these exceptions are WARN with the exception
message only or at DEBUG with the full exception.
The user template ldap implementation could potentially cause a lot of
logging to be generated because it always prints the full exception at WARN
level. This changes it to print the message at WARN level and the exception
at DEBUG.
Original commit: elastic/x-pack-elasticsearch@c607567d88
Use in:
- Determining the execution time of an alert
- The period throttler to determine the time passed since last execution
Original commit: elastic/x-pack-elasticsearch@9197b86b68
- the transform parser and registry can now parse transform results
- every transform result may have its own format
- the chain transform result outputs the "transformation trail" of all the chained transforms (great tool for debugging)
- removed `Transform.NOOP` - was redundant, when no transform is defined the alert's transform is `null`
- removed `payload` from the `AlertExecution`. Instead, the execution holds the input result, transform result and potentially the transform results of the actions
- changed the xcontent representing a transofrm result to `{ "transform_type" : { "payload" : {...}, ... } }`
- with this change, the `Action` interface is cleaned up (`execute` only accepts the execution context)
Original commit: elastic/x-pack-elasticsearch@6ecf7f2c92
An alert may have multiple actions associated with it, but each action may need to have different view of the data. For example, the email may need a certain model for its templates while the index or webhook actions may need a completely different data structure.
Until now, there's only an option to defina a single `transform` on the alert level that would have applied to all actions. This commit adds
the ability to associate a transform with each action. We still keep the tranform on the alert level (in case all actions need the same transformation, in which case we'd like to avoid repetition).
Original commit: elastic/x-pack-elasticsearch@5493a2179b
jaymode
Martijn van Groningen
Brian Murphy
uboness
Alexander Reelsen