-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[APM] Create multi-signal service inventory : Tech Preview 'off' by default #183012
Comments
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
I have created this ticket #182675 based on the initial AC. Happy to close it as duplicate but can we update this one to have only the requirements for this iteration? ex, Must Have and & Will Not Have (for now) It would be really useful if the implementation tickets are as concrete as possible . it does help both the engineer and the reviewer. @roshan-elastic wdyt? |
Ah sorry @kpatticha - I completely missed that and thanks for flagging! I was working with @cauemarcondes on this. The 'must have' requirements are the only things required for this first iteration. Is that OK or is there anything that could make this clearer? |
@roshan-elastic the must have requirements are clear. However, I would appreciate it if the ticket includes only the things necessary for this first iteration. |
No worries @kpatticha. Could I ask about this to understand a bit more? I just want to make sure I structure these issues in the right way moving forwards. Should these implementation issues only have the minimum criteria for success or should they have stretch goals in there too (e.g. could have)? I'm OK either way - I'm just trying to figure out where (or if) we should put things which aren't critical in this kind of ticket. Thanks! |
APM errors use |
pause this work for a bit to work on #183818 in order to match the output of the entities. |
resume the work on the UI. |
@chrisdistasio / @tommyers-elastic / @kpatticha Getting Log Rate and Log Error % to work in Service Inventory for services with only logs, only APM or bothKate and I were discussing how the 'log rate' and 'log error rate' columns would work in the new Service Inventory and also ensuring users can dig into these logs by going to the logs tab in the service view. Where we'd like to end up is that this works for services with only logs, only APM or both. Looking at the data, I'm wondering whether we can might be able to achieve this with some small configuration? My Test on
|
## Summary fixes elastic#183012 - Rename `assets` to `entities` - Update entities index: `.entities-observability.latest-*` The index where the data transform writes the summaries - Show a search field to filter by service name. This will allow the user to filter the table without knowing the entities index and the fields. - Use the same template and path for the service inventory`/services` . - `throughput` remains the initial sorting field - Merge the entities with the the same service name and calculates the averages in the front end https://github.com/elastic/kibana/assets/3369346/2dbc07e9-3086-4d32-a98e-5dc364f59554 ### How to test 1. Add the config to your kibana.yml ``` xpack.assetManager: alphaEnabled: true ``` 2. Enable `observability:apmEnableMultiSignal` in advansted settings <details> <summary>3. Run the entities definition in the dev tools</summary> ``` POST kbn:/internal/api/entities/definition { "id": "apm-services-with-metadata", "name": "Services from logs and metrics", "displayNameTemplate": "test", "history": { "timestampField": "@timestamp", "interval": "5m" }, "type": "service", "indexPatterns": [ "logs-*", "metrics-*" ], "timestampField": "@timestamp", "lookback": "5m", "identityFields": [ { "field": "service.name", "optional": false }, { "field": "service.environment", "optional": true } ], "identityTemplate": "{{service.name}}:{{service.environment}}", "metadata": [ "tags", "host.name", "data_stream.type", "service.name", "service.instance.id", "service.namespace", "service.environment", "service.version", "service.runtime.name", "service.runtime.version", "service.node.name", "service.language.name", "agent.name", "cloud.provider", "cloud.instance.id", "cloud.availability_zone", "cloud.instance.name", "cloud.machine.type", "container.id" ], "metrics": [ { "name": "latency", "equation": "A", "metrics": [ { "name": "A", "aggregation": "avg", "field": "transaction.duration.histogram" } ] }, { "name": "throughput", "equation": "A / 5", "metrics": [ { "name": "A", "aggregation": "doc_count", "filter": "transaction.duration.histogram:*" } ] }, { "name": "failedTransactionRate", "equation": "A / B", "metrics": [ { "name": "A", "aggregation": "doc_count", "filter": "event.outcome: \"failure\"" }, { "name": "B", "aggregation": "doc_count", "filter": "event.outcome: *" } ] }, { "name": "logErrorRate", "equation": "A / B", "metrics": [ { "name": "A", "aggregation": "doc_count", "filter": "log.level: \"error\"" }, { "name": "B", "aggregation": "doc_count", "filter": "log.level: *" } ] }, { "name": "logRatePerMinute", "equation": "A / 5", "metrics": [ { "name": "A", "aggregation": "doc_count", "filter": "log.level: \"error\"" } ] } ] } ``` </details> 4. Generate data with synthrace 1. logs only: `node scripts/synthtrace simple_logs.ts` 2. APM only: `node scripts/synthtrace simple_trace.ts` ### Checklist - [ ] There is a issue with the `SearchBar` that causing the gap between the search field and the timerange. I need to check it
📖 Description
Create initial multi-signal service inventory under tech preview (off by default)
🎨 Designs
See Figma
✔️ Acceptance criteria
1. Must Have
Must be delivered in this issue in order for the release to be valuable
This is because when you click through into the APM view, there will be no capability to debug these logs (and also, log error rate is not simple for APM logs as there is no
log.level
). We will figure this out in a future iteration.service.environment
2. Should Have
Should be delivered in this issue in order for the release to be valuable
3. Could Have
Could be delivered in this issue in order for the release to be valuable
4. Will Not Have (for now)
Explicitly will not be looked at within this issue
📈 Telemetry Process
The text was updated successfully, but these errors were encountered: