Logging

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
• Graphweaver Internals
• SQL Queries
• Deployed Application

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 scenarios
• error
• warn
• info - Default
• debug
• 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.