Observability
This article briefly describes the observability options that are available to a Backstage integrator.
Datadog RUM Events
See how to install Datadog Events in your app here
Logging
New Backend
The backend supplies a central logging service, rootLogger
, as well as a plugin based logger, logger
from coreServices
. To add additional granularity to your logs, you can create children from the plugin based logger, using the .child()
method and provide is with JSON data. For example, if you wanted to log items for a specific span in your plugin, you could do
export function createRouter({ logger }) {
const router = Router();
router.post('/task/:taskId/queue', (req, res) => {
const { taskId } = req.params;
const taskLogger = logger.child({ task: taskId });
taskLogger.log('Queueing this task.');
});
router.get('/task/:taskId/results', (req, res) => {
const { taskId } = req.params;
const taskLogger = logger.child({ task: taskId });
taskLogger.log('Getting the results of this task.');
});
}
You can also add additional metadata to all logs for your Backstage instance by overriding the rootLogger
implementation, you can see an example in the logger
docs.
Old Backend
The backend supplies a central winston
root logger that plugins are expected to use for their logging needs. In the
default production setup, it emits structured JSON logs on stdout, with a field
"service": "backstage"
and also tagged on a per-plugin basis. Plugins that
want to more finely specify what part of their processes that emitted the log
message should add a "component"
field to do so.
An example log line could look as follows:
{
"service": "backstage",
"type": "plugin",
"plugin": "catalog",
"component": "catalog-all-locations-refresh",
"level": "info",
"message": "Locations Refresh: Refreshing location bootstrap:bootstrap"
}