Sometimes things are going wrong and you’re not sure what’s happening. Here are some tools you can use to get more insight into what’s going on.
Performance Debugging
If you’re trying to figure out why something is slow, the first step is to enable the OpenTelemetry integration with the internal collector. This will show you what is required to service a particular query or mutation, and allow you to figure out what component is slow (and therefore what you should focus on optimising first).
Graphweaver Internals
Logging within Graphweaver is handled by Pino. To change the logging level, set the LOGGING_LEVEL
environment variable. Available levels are:
fatal
- Least verbose, only logs in fatal scenarioserror
warn
info
- Defaultdebug
trace
- Most verbose, as much logging as we can give you
Usually to debug you’d want to set logging to trace
which you can do easily by setting the variable inline when you start your project, like this:
$ LOGGING_LEVEL=trace pnpm start
SQL Queries
It’s sometimes quite useful to see what queries are going to the database. You can log them by setting the DEBUG
environment variable to knex:query
, like so:
$ DEBUG=knex:query pnpm start
It can also be useful to configure your database to log statements and look at that log separately from the application output.
- In PostgreSQL you can use the log_statement option.
- In MySQL you can use the general query log.
Deployed Application
Once your Graphweaver instance is deployed, it’s important to remember that the more the application logs, the slower it’ll be as the more work it has to do. Try to balance the amount of logging with storage costs and performance needs for your specific use case.