Alarm callback search results payload broken #923
Comments
The underlying problem is that eventually this gets called: public void addField(final String key, final Object value) {
// Don't accept protected keys. (some are allowed though lol)
if (RESERVED_FIELDS.contains(key) && !RESERVED_SETTABLE_FIELDS.contains(key) || !validKey(key)) {
// ...
} so that the id is not being set into the message. |
for HTTPAlarmCallback, the new structure of the messages that match the stream alert condition is the following: "matching_messages": [
{
"index": "graylog2_2",
"message": "GET \/posts [200] 73ms",
"fields": {
"http_method": "GET",
"took_ms": 73,
"http_response_code": 200,
"gl2_source_input": "54c77720d4c6b8c648cd1103",
"gl2_source_node": "38048b35-034f-4212-9b1c-f7cec9f6acef",
"action": "index",
"resource": "\/posts",
"user_id": 6469981,
"controller": "PostsController"
},
"id": "b9eb78f0-a632-11e4-8869-8a3dffaa2055",
"source": "example.org",
"stream_ids": [
"54c77687d4c6b8c648cd105f"
],
"timestamp": "2015-01-27T14:42:32.575Z"
}
] the data is also accessible to other plugins, via AlertCondition.CheckResult#getMatchingMessages. The original method getSearchHits() on the AlertCondition is still present but deprecated and will be remove from a future release. |
…ultMessage this happened in AlarmCallbacks, where Message objects were created without required fields (thanks to addFields which checked for _id…) #923
@lennartkoopmann do you want to add the new json format to the documentation? |
When I tried to adapt an AlarmCallback Plugin to the new structure, I found this issue and realized that the original The method getMessage() only returns the |
We encapsulated it because the Message class was in no way meant to be an API (and actually is a mess that will need serious refactoring). |
@dfch In which case are you unable to retrieve a field from MessageSummary? |
@kroepke maybe I was not clear on that, I can use
Side note: I do not understand why you do not want to make |
The reason we moved it out of AlarmCallbacks was that the Message object was blindly serialized as JSON with "funny" results. We needed to fix that immediately. All other plugin types suffer from the same problems regarding the Message class "API", but we didn't have an immediate problem there. Specifically, Message has references to other internal objects that plugins should really have no business dealing with (like MessageInput). We can certainly add those two methods if that makes life easier. |
It is just a thought, I certainly realise that there are more important issues waiting. So if you were going to change the |
The search hits in an alarm callback are kinda broken. (See
search_hits
in payload below)The serialized
Message
objects lack theid
and other fields. There should be a separate DTO with Jackson annotations for this because this is an API. Also, theMessage
object needs to be built correctly including all fields.Currently all fields of the raw object are exposed.
The text was updated successfully, but these errors were encountered: