In your plugins, everything that is written through the Plugin SDK Logger class will be available as logs. Logs are written in a stream dedicated to the plugin's organisation.
In order to ease the log search process, you may want to systematically add some context informations to logs, like feed ID, site ID, app ID, ... That way you'll be able to filter on a specific instance of your plugin to see logs.
A sample use of the Logger class

Accessing your logs

If you don't already have an access, ask your Account manager for an access to your organisation's plugin logs.
You can check plugin's logs on
Click on your organisation's stream. The stream name is built in the format "{Organisation ID} {Organisation name}"
You should already have a stream for your client's organisation. If not, ask your Account manager to create one. Please provide them with the organisation ID, the datamart ID and the emails and names of people that should have access to this stream.
Once on the stream, you can see all incoming logs. You can select a time span for logs visualization, search for particular properties and start automatic refreshes in order to see logs as they arrive.
Command bar to search for the logs you need

Advanced filtering

You can directly use the search if you know the syntax. Or you can use the left Fields panel to help you generate queries.
You can select the files you want to see with each line of logs, and use the arrows to show additional actions for each field.
Click on Quick values to show the different available values for a field. For example on the plugin artifact ID field to filter on a particular plugin for your organisation.
Quick values for plugin artifact ID
Simply click the search icon on the line of the value you wish to filter on. The query will automatically be added to the search query. Start a refresh and you now only see the logs for one particular plugin !
You can get familiar with the search query language on Graylog's official documentation.

Log levels

You can use logs with different levels:
  • Error
  • Log
  • Info
  • Debug
You should aim to not generate too much logs. If it happened, mediarithmics would stop your stream from logging in order to protect all the other streams.
You can use Debug severity for log intensive activities, like tracing data and functions. Debug logs are not saved by default, and you can ask your Account manager to temporarily enable them. That allows you to prepare your code for tracing, without generating useless logs all the time.
A good practice to have clear logs is to generate stats every X seconds. For example, instead of showing a message at every item, you could show the number of items processed every X seconds and their status.
Last modified 1yr ago