https://signoz.io logo
Join Slack
Powered by
Suggestion/Comment/Thought/Feedback. One of the t...
# general
b
Suggestion/Comment/Thought/Feedback. One of the things that I've been trying to do is somewhat recreate the new relic dashboard. I realize it isn't perfect, but it's a good starting point. One of the graphs that I find very useful is the amount of time spend in different areas of the code (specifically, database, application, and eternal calls). I struggled a bit to get that displayed in signoz. What I ended up doing is using grafana with the clickhouse datasource to recreate it (and it worked, for the most part). I might suggest that focusing on trying to recreate something like the New Relic Dashboard might help adoption of SigNoz. Having that kind of information available right out of the box would be amazing.
I think of everyone I have worked with, that's the biggest complaint of something like Grafana. "All the data is here, but now I have to put it together or even understand what it is". That's one of the things that places like new relic get right
p
Thanks for the suggestions @Brad Misterek. We have some updates coming around this with out of the box dashboards.
One of the graphs that I find very useful is the amount of time spend in different areas of the code (specifically, database, application, and eternal calls).
Trying to understand this use case a bit better - was the out of the box graphs in SigNoz with latency, DBs and external not helpful for this. Can you share the dashboard which you used in Grafana so that we can get a better idea of what you were trying to see
b
I may need to upgrade (on 0.21.0), but I do see the information on different tabs. The graph that I'm referring to in new relic is essentially this one:

https://i.ytimg.com/vi/EGMacfyuA9w/maxresdefault.jpg▾

On one handy graph, you can see your overall response time, and the components that went into it. i..e "our response time was bad at 9am" --> loook at a graph like that, and you can quickly get a sense of what the issue was. For instance, in a graph like that, you might see that your database component stayed normal, but your application code was way slower. Or an external call (say, to an API) was very slow so your response time slowed down. Or your database took up the bulk of it. Etc...
It doesn't tell you everything, but often I find it helps me get closer to the root cause quicker
My (terrible) queries that I use for External and Database are:
Copy code
# External
SELECT DATE_TRUNC('minute', timestamp) AS interval, SUM(durationNano) / 1000000 as ms
FROM signoz_traces.signoz_index_v2
WHERE externalHttpMethod!='' AND  serviceName='myservice' 
GROUP BY DATE_TRUNC('minute', timestamp) ORDER BY interval ;


# Database
SELECT DATE_TRUNC('minute', timestamp) AS time, SUM(durationNano) / 1000000
FROM signoz_traces.signoz_index_v2
WHERE dbName!='' AND  serviceName='myservice'  
GROUP BY DATE_TRUNC('minute', timestamp) ORDER BY time ;
And then my "other" bucket is just latency minus those two numbers. Also, note -- I wouldn't say these are super great, but it is the road I'm going down, since this is the kind of information that I find useful. I'm not sure the Ruby OTEL collector gives me the best data to work with. And, all that being said, I may have been able to build similar in the signoz dashboard. BUT, i think having something like that working out of the box would be amazing.
Anyway, feel free to disregard any of this if it isn't helpful. I'm not sure new relic is my favorite tool, but one thing it does well is has a landing page that helps me very quickly get to the right area for issues
And maybe that's how I'd articulate it. There are 2 reasons I'm looking at an APM: • To take a look. See waht I can optimize. I have all the time in the world for this. • Something is wrong and I need to find out what and why as fast as possible.
2 Views
Open in Slack
PreviousNext
Powered by