Thanks @raj and everyone for the additional information and for keeping this on the radar! We’ve merged some PRs that will hopefully address all of these. I’ll prioritize getting a new version of studio out so we can all have a better experience!
Hi,
I am wondering if this feature is being maintained? It is pretty nice, but the dependencies haven’t been upgraded for a while. Is it something I can easily do in user land?
Kind regards!
1 Like
We will maintain this feature and although I’m not quite certain what has been released yet we have been merging dependency upgrades related to opentelemetry. We probably don’t have any time at the moment to make feature style improvements but I’ll make sure to double-check check we get these sort of dependency upgrades out in our next release.
Sorry, I think I need a bit more clarification.
I have added opentelemetry quite early in the experimental phase. So now I am wondering if I even need these in my api package.json or if redwood would update them.
I am on redwood v 7.3.0. These are the versions I have on package.json api side:
"@opentelemetry/api": "^1.4.1",
"@opentelemetry/exporter-trace-otlp-http": "^0.40.0",
"@opentelemetry/instrumentation": "^0.40.0",
"@opentelemetry/instrumentation-fastify": "^0.31.4",
"@opentelemetry/instrumentation-http": "^0.40.0",
"@opentelemetry/resources": "^1.14.0",
"@opentelemetry/sdk-node": "^0.40.0",
"@opentelemetry/semantic-conventions": "^1.14.0",
"@prisma/instrumentation": "^4.16.2",
I also see version 1.7.0 of @opentelemetry/api in my yarn.lock on @redwoodjs/graphql-server@7.3.0
Should I update those opentelemetry and prisma instrumentation dependencies myself?
1 Like
Ah yeah sorry I see now! As this is an experimental feature we don’t provide codemods or anything like that to upgrade the opentelemetry dependencies for you. It would be a manual process on your end.
My technique here would probably be to ensure my code was properly checked in to git. Run the setup command again to get whatever the latest redwood implementation is - probably only the dependencies have changed but we might have also updated the default template. I’d then resolve any conflicts with duplicated dependencies or the template files.
I know resolving conflicts isn’t the most fun but until we have time to properly scope out exactly how we want opentelemetry to enhance redwood projects this will likely stay as experimental. I’m hoping that with the introduction of RSC we’ll be able to leverage opentelemetry more to provide better insight and tooling for RSC and non-RSC projects. That’s future work though so for now yeah it’s unfortunately a manual process 
1 Like
Thanks a lot! This is helpful 
1 Like
Hi,
Open Telemetry setup tells me to add this:
✔ Notice: GraphQL function update (server file)...
› Please add the following to your 'redwoodFastifyGraphQLServer' plugin options to enable OTel for your graphql
openTelemetryOptions: {
resolvers: true,
result: true,
variables: true,
}
Which can found at /home/martin/Repositories/RW_NEW/api/src/server
currently this is not documented here on this site.
My typescript complaints, so i am wondering if this is correct.
It also feels redundant, since we also should do it in createGraphQLHandler
Should I do it as shown on the image?
Tried. it works well, i could easily push up metrics to grafana. Any plans on making it available for production env via a flag?
Has anyone managed to get this working in a deployed environment?
I can get this working locally, but once I deploy the changes (via Docker + AWS ECS) there’s no indication that the opentelemetry.ts script is getting loaded. Ultimately I’d like to export the traces to Datadog, but right now I can’t even get the opentelemetry.ts script to log a debug statement.
I notice the experimental.opentelemetry.enabled TOML configuration is being used to toggle a --require option on server hot reloads. Is there something similar happening for the api builds for production deploys? If not, is there a way I can pass the --require option myself?
I think I can use NODE_OPTIONS
confirmed NODE_OPTIONS works. To summarize, you can get around the current limitation of yarn rw serve not supporting the experimental.opentelemetry.enabled config with NODE_OPTIONS="--require api/dist/opentelemetry.js" yarn rw serve
3 Likes
Hello, I tried adding GraphQLInstrumentation to registered instrumentation list, but that did not give me anything in the GraphQL monitor on the Dashboard, all of the other Dashboard graphs actually have data and I can see stuff coming to the studio. What I want to do in the end, is monitor my grapqhl query and mutation performance, like what we get with morgan for express. I also have an Elastic APM Server, that I would like to plug this into, but was not able to do so far with success, anyways I need to see GraphQL metrics on RW Studio first, then try integrating this to Elastic APM, any help with this is appreciated.
Hi @hazimdikenli could you share how you instrumented?
Instead of trying with Studio I would recommend using one of the Yoga and envelop plugins for a specific provider since you intend to capture in production: Plugins (Envelop)
Specifically the metric category.
You can use and configure directly each based on what you need.
I did not specify any configurations, just passed the default version to the list.
registerInstrumentations({
tracerProvider: provider,
instrumentations: [
new HttpInstrumentation(),
new FastifyInstrumentation(),
new PrismaInstrumentation({
middleware: true,
}),
new GraphQLInstrumentation(),
],
})
and it is imported fom;
import { GraphQLInstrumentation } from '@opentelemetry/instrumentation-graphql'
Ok - I highly suggest using the OT plugin for Yoga:
You’ll add via:
/**
* @description Custom Envelop plugins
*/
extraPlugins?: Plugin[]
in the GraphQL handler config: