schema updates #170
schema updates #170
Conversation
| "timestamp": { | ||
| "type": "date", | ||
| "format":"rfc3339_lenient||epoch_millis", |
| "type": "keyword" | ||
| }, | ||
| "application": { "type": "keyword", "ignore_above": 256 }, | ||
| "action_name": { "type": "keyword", "ignore_above": 100 }, |
There was a problem hiding this comment.
should we roll these into the spec then as well?
There was a problem hiding this comment.
I thought they were???
| } | ||
| "internal_id": { "type": "keyword" }, | ||
| "object_id": { "type": "keyword", "ignore_above": 256 }, | ||
| "object_type": { "type": "keyword", "ignore_above": 100 }, |
There was a problem hiding this comment.
are we still doing object_type? we should chat since we don't have that in the spec, are we missing it? I guess I was assuming an object_id would tell you everything you needed to know....
There was a problem hiding this comment.
I think we need it. At the very least, in the js you can stuff anything into an object. So, for example, I cram the whole javascript timer in there because it has other cool info that someone might want.
That aside, I'm sure someone will have multiple kinds of things/objects/cats/dogs with the same id.
| "timestamp": { "type": "date" }, | ||
| "query_id": { "type": "keyword", "ignore_above": 100 }, | ||
| "query": { "type": "flat_object" }, | ||
| "query_response_id": { "type": "keyword", "ignore_above": 100 }, |
There was a problem hiding this comment.
we should probably get on the same page on what query_response_id is, again, we odn't have it in the spec, is this an internal thing?
There was a problem hiding this comment.
This is a difference in the mappings vs the request/response schema. This is for indexing the query_response_id, not returning it in a response.
There was a problem hiding this comment.
query_response_id is a unique id per OS response to the client.
Theoretically, a client could reuse the same query_id several times to query something, but the query_response_id should always be unique.
|
i am going to go throught this and get this sorted, so we can get #169 done |
| @@ -1,114 +1,50 @@ | |||
| { | |||
| "dynamic": true, | |||
There was a problem hiding this comment.
@RasonJ is going to look at moving this down INTO the event_attributes stanza so you can have dynamic fields in there. That would map to the specifiation that says "Additional Properties of any type allowed": https://o19s.github.io/ubi/docs/html/event.schema.html#event_attributes_object_additionalProperties
… to `object_id_field`
Notes & Questions:
I couldn't find a single date-time format spec that matched the json schema format, but if you add
ignore_malformedOS saves the date-time regardless.More questions on the query index:
client_id? It'd make it much easier to do top queries per "client" with it.user_queryandquery_attributesto the query index? Would the plugin save to those fields?