Logging
Logs from a worker only become useful when they are tied back to the process and message they belong to. The SDK gives you a logger that does this correlation automatically; use it instead of console.log or error_log.
Use the SDK logger #
import logger from '@orchesty/nodejs-sdk/dist/lib/Logger/Logger';
public async processAction(dto: ProcessDto): Promise<ProcessDto> {
logger.info('Hubspot list contacts started', dto);
try {
// ...
logger.info('Hubspot list contacts done', dto);
} catch (e) {
logger.error('Hubspot list contacts failed', dto, e);
throw e;
}
return dto;
}
When you pass the dto (or in PHP, the array containing it), the logger automatically attaches:
correlation_id(the process id)topology_id,topology_namenode_id,node_nameapplication_idanduserif present
What to log #
The cheap, durable answer:
- One info line at start. "About to call Hubspot for user X."
- One info line at end. "Got 247 contacts back."
- Error lines on every catch. Include the exception, the call's input, and what the next step would have been.
The expensive, easy-to-regret answer:
- A debug line per loop iteration. Useful while developing, painful in production.
Treat anything between start and end as something a future you will not be reading.
What not to log #
- Credentials. Never. The SDK doesn't, you shouldn't.
- Full upstream payloads with personal data unless your logging stack is GDPR-cleared.
- Full image, file, or large blob bodies. Log a checksum and a size instead.
Where logs go #
In the full-stack setup, logs from the worker container land in the platform's log store and are visible from the process detail in the Admin UI, joined to the right process automatically. In a worker-only setup, logs go to stdout of the worker process; ship them with whatever logging stack you already use (Datadog, Loki, ELK).