Comments (9)
@crbelaus @gmile We're considering supporting this feature by adding the last line of the backtrace (the one further from Ecto's internals) in the event. Here's a quick mockup with placeholder text:
You would be able to click on a "git" icon next to it and see the corresponding source code in GitHub. Would this be useful to you?
from appsignal-elixir.
Hi, @unflxw! Happy to hear AppSignal is considering implementing this feature. Noted that you're considering to report a location line emitted right before Ecto's internals.
Regarding your screenshot, would lib/task/supervised.ex:36
be the location where the query originates from? Or is this just happens to be a non-ideal example?
My point is, the chosen line of backtrace should be pointing to a location in application code, and not from Ecto nor from Elixir internals. But on your screenshot it appears to be coming from Elixir internals, as suggested by lib/task/supervised.ex:36
, which is less than ideal I think 🤔
from appsignal-elixir.
This would be a very welcome improvement. I am also in the process of fixing some slow queries in my application (also very big) and sometimes it is really hard to correlate the query with the code that triggers it.
from appsignal-elixir.
Hey Ievgen and Cristian,
I do agree that it might be useful to know where queries are executed, but we're currently not set up for that. Right now, events don't support stack traces unless they have an error attached to them.
Also, I'm not sure what the performance impact of reporting stack traces for every query would be. Not specifically on AppSignal's side, as adding data to the span should be fairly quick, but calculating the stack trace might have an impact on high-throughput applications, so I'm not sure if I'd recommend this for production use.
I'll keep this issue open to allow for some discussion about this and to maybe pick this up in the future, but it's not something we'll be picking up in the coming period, I'm afraid.
from appsignal-elixir.
While fixing slow queries I've found two different situations:
- Slow queries that are directly executed in a Phoenix request or an Oban job are correctly linked to the code that runs them. If there is an error, it show in the "web" or "oban" namespace accordingly.
- Other queries seem not to be linked to any part of our codebase so there is no way to find the offending code other than searching for the query manually. In this case errors are not linked to the code either and show in the "background" namespace.
I think that the second kind of query is the problematic one. When there are errors I always see the following in AppSignal's stacktrace:
lib/ecto/adapters/sql.ex:913 Ecto.Adapters.SQL.raise_sql_call_error/1
lib/ecto/adapters/sql.ex:828 Ecto.Adapters.SQL.execute/6
lib/ecto/repo/queryable.ex:229 Ecto.Repo.Queryable.execute/4
lib/ecto/repo/queryable.ex:19 Ecto.Repo.Queryable.all/3
lib/ecto/repo/preloader.ex:272 Ecto.Repo.Preloader.fetch_query/8
lib/task/supervised.ex:101 Task.Supervised.invoke_mfa/2
lib/task/supervised.ex:36 Task.Supervised.reply/4
The Ecto.Repo.Preloader
is always present so this makes me think that those queries may be the result of a parallel preload, which is not currently being linked to the parent span, so AppSignal cannot correlate it with the proper action.
This has been reported on #603 and I think that it may be the same issue. In #603 there is a link to an ElixirForum post with a potential fix to link parallel preload queries to the parent span but I did not try it yet myself.
from appsignal-elixir.
Hi @gmile! My apologies, it is placeholder text -- I quickly copy-pasted a line of an Elixir backtrace from your comment above.
Ideally we'd pick the line in the backtrace that is furthest from Ecto internals, as that line is the most likely one to be close to the developer's code, and as such meaningful to the developer. Going from the sample logs in elixir-ecto/ecto#3798 (comment), that would be EctoBug.reproduce/1
:)
from appsignal-elixir.
@unflxw noted that it's a sample glitch :) In this case the answer to your question is yes, this certainly would be very useful!
from appsignal-elixir.
I also agree with @gmile, it would be extremely useful!
from appsignal-elixir.
Since this issue is seen as a workaround for #603, I have decided to first approach fixing #603 in isolation, then look into implementing this.
While it is true that having stacktrace information would work around the loss of context on the query caused by #603, the two are fundamentally different issues.
from appsignal-elixir.
Related Issues (20)
- Drop support for unmaintained Elixir/Erlang versions
- Provide logging feature through a logger handler HOT 1
- Are calls to `add_distribution_value` synchronous or asynchronous? Can they raise errors? HOT 2
- Neon startup causes errors to be sent to AppSignal HOT 2
- (Mox) testing guidelines? HOT 3
- Oban "Insert job" should not be a root span HOT 1
- AppSignal causes Phoenix to seg fault when a request is received on MacOS 13.6 HOT 12
- Expose a way to clone the Tracer stack for a process HOT 2
- Allow for additional context to be added to Tesla calls
- Memory leak when running long, work intensive Oban background job HOT 10
- Jobs cancelled via Oban Web are not properly closed
- `Logger.error` does not log AppSignal Error HOT 2
- Clickable stack traces to directly jump into the source HOT 1
- Allow setting per-process metadata to unhandled exceptions HOT 3
- Consider sharing exception "blame" information to aid debugging HOT 1
- Alpine aarch64-unknown-linux-musl unknown architecture HOT 2
- Elixir parameter filtering does not match Phoenix's behavior
- Include last message from genserver shut down HOT 1
- LiveComponents shown in "background" namespace HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from appsignal-elixir.