-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Meta] Observability TSDB packages migration #5233
Comments
Question : Should timeseries enablement be done on datastream type of type If the answer is Case A : TSDB enablement is needed on logs datastream
Sharing an observation (can become a potential problem as well) and a usecase issue here Observation : Logs of various type and structure may fall into access log, error log . Certain integrations such as Usecase a ) Logs such as audit trails are not centered around metrics, have keyword type fields used more often. Are there any benefit in TSDB enablement in an audit-trail usecase scenario ? b) There exist log data stream such as Case B : TSDB Enablement is NOT needed on logs datastream In Kibana UI, there must not be a selection when a datastream is having a My recommendations are as below
@ruflin , @lalit-satapathy , can you please validate the above two cases (case A, caseB) and my proposed recommendation and share your thoughts ? |
No. I recommend to ignore everything around logs right now.
Agree. The flags will be reworked in the upcoming releases ( @kpollich )
This is an interesting point. Do you expect some |
I am suggesting this as a general rule to follow irrespective log type or metric type. This is because, there may exist a few datastreams having type based on http_json ( type : log ) having metric_type value gauge. Since we don't have all the |
Should these be |
@lalit-satapathy , i believe, there was a discussion on this topic , much before TSDB migration started, regarding this topic. Was any decisions made? |
For now, lets focus only on |
Updated meta issue to track all O11y TSDB packages. Segregating packages to ongoing/completed/blocked and issues to elasticsearch/Kibana/Others. |
Updated Issue Summary in meta to: clearly call out blocker/critical and also track what is the pending action. Also, cleaned-up old issues and updated severity as applicable. |
There are no further plans for aggregations on counter fields. There is documentation that describes which aggregations are allowed on counter fields: https://www.elastic.co/guide/en/elasticsearch/reference/8.7/tsds.html#time-series-metric
Is this an Elasticsearch issue or an elastic-package issue? The default number of dimensions is 16 in 8.7 and this will be increased to 21 in 8.8 |
@nimarezainia @joshdover do you think the 4 issues ( 1 blocker and 3 critical) we have raised for the adoption of TSDB in observability are solvable for 8.8.0?
See table above for reference of all issues found and raised. @giladgal who from the fleet team is involved in TSDB? |
Updated "Issue Summary" with latest issues. |
Closing the top level meta issue. |
Migration summary
Important resources:
Spreadsheet listing package prioritisation (private link)
Packages are being migrated dataset wise, following the generic guideline here. The scope of the migration is to cover both addition of dimensions and metric types.
Mandatory ECS fields: [ECS] [TSDB] Centralisation of Dimension Fields #5193 (comment)
Testing the migration: https://github.com/elastic/TSDB-migration-test-kit
Packages ongoing
Completed packages
Blocked packages
User reported issues
Internal o11y issues found
scaled_float
fields are not searchable. Related issueThe text was updated successfully, but these errors were encountered: