Update stack monitoring spec 3.x #12156
Conversation
andrewkroh added dashboard 
🚀 Benchmarks reportTo see the full report comment with |
This package is intended for versions of kibana over 8.10.2. Kibana till 8.16 was filtering out packages up to 3.0 versions. |
| Thanks @jsoriano
Where can I learn about such Kibana-specific constraints? |
There was a problem hiding this comment.
The reason for switching to flattened is because otherwise object_type would be required?
There was a problem hiding this comment.
Correct, type: object alone is not allowed because it is like an empty mapping.
I could not find an example document with this field, so I have chosen flattened as a quite safe option. But it would be indeed better to provide a more specific mapping. Do you know what is the structure of these fields?
There was a problem hiding this comment.
You can actually find a sample event containing some data for that field here, which only contains two subfields, one keyword and one text, which I guess rules out the object_type option altogether:
"read_exceptions": { "type": "nested", "properties": { "exception": { "type": "object", "properties": { "reason": { "type": "text" }, "type": { "type": "keyword" } } }, Also interesting is to see how that field is actually used in Stack Monitoring, i.e. the query only checks for the existence of the exceptions object (which flattened also supports), and then the type subfield is read.
I'll do some more checks to see if changing from object to flattened doesn't break anything (also in the case of monitoring indices not having the same mapping after rollover)
There was a problem hiding this comment.
Well, these mappings with nested sound good too, I can try with them.
| As a result of seeing the output of |
At the moment this is only in the default kibana configs. We should probably document this somewhere else, similar to what we have for kibana constraints in https://github.com/elastic/elastic-package/blob/main/docs/howto/stack_version_support.md#when-to-update-the-condition. |
| Adding guidelines for spec version to elastic/elastic-package#2291 |
packages/elasticsearch/manifest.yml Outdated
There was a problem hiding this comment.
This is the first safe version to use secrets. We can also delay the adoption of secrets, then I would revert the change in the kibana constraint, and set secret: false in the cases where it is set to true now.
There was a problem hiding this comment.
I think it should be fine bumping from 8.10.1 to 8.11.2
andrewkroh added the Team:Stack Monitoring There was a problem hiding this comment.
Shouldn't this be just read_exceptions since exception is now a field of its own below?
There was a problem hiding this comment.
You are right, good catch, thanks.
There was a problem hiding this comment.
Ok, I hadn't noticed that there was already a definition from these fields. I think we only need to remove the definition of the read_exceptions.exception object.
packages/beat/manifest.yml Outdated
There was a problem hiding this comment.
This should also probably be 8.11.2
There was a problem hiding this comment.
I haven't updated the version here because this package doesn't make use of secrets, or afaik anything not available in 8.10.
|
| Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
💔 Build Failed
Failed CI StepsHistory
cc @jsoriano |
|
| Elasticsearch migration to spec 3.0 is blocked by elastic/package-spec#868 after the recent addition of transforms in the package. |
andrewkroh added Integration:1password | Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
qcorporation force-pushed the main branch 2 times, most recently from eda4138 to f728ca7 Compare 4 participants
Migrate stack monitoring packages to spec 3.x.