Logger
# dev
j
As a follow up to this thread: https://discord.com/channels/905144809105260605/1113936455954346005/1141738248805298218 Would Medplum consider using a logging library again? Or exposing an option to provide a custom logger? Or some 3rd thing I'm not thinking of (other than a fork)? We're trying to do distributed tracing through our API to Medplum (with Datadog's dd-trace). The stack traces work perfectly, it's super cool. But one feature we are missing is connecting logs to traces. We need to be able to emit a trace id in log messages in each service. dd-trace automatically patches winston, pino, et al - but console.log requires manually writing the trace id. So far we've come up with this truly awful Dockerfile option where we patch console.log:
Copy code
FROM medplum/medplum-server:latest as medplum
RUN npm install --save dd-trace
RUN echo "const tracer=require('dd-trace'),formats=require('dd-trace/ext/formats'),originalConsoleLog=console.log;console.log=(...args)=>{const span=tracer.scope().active(),record={};if(span){tracer.inject(span.context(),formats.LOG,record);}if(args.length===1){try{let parsedArg=JSON.parse(args[0]);if(typeof parsedArg==='object'&&parsedArg!==null){args[0]=JSON.stringify({...parsedArg,...record});}}catch(e){}}originalConsoleLog(...args);};tracer.init();" > tracer.js
ENTRYPOINT [ "node", "--require", "./tracer.js", "packages/server/dist/index.js", "env:" ]
r
@joshua_kelly this is something that's top of mind to us. We've written up a github discussion with our current thoughts here https://github.com/medplum/medplum/discussions/2759
Would it address your use case if we just supported trace IDs directly? One solution we're considering is to read them out of some standard header and insert them into all logs for that request
j
I'm pretty sure yes, I'm almost certain that we can control the trace id header that we send in our request
I think the broad strokes of this are exactly right: * Align with OpenTelemetry * Support tracing * Support metrics The logger is really a red herring here -- with OT you could end up in a place where you have strong observability primitives that work in your hosted AWS version, self-hosted AWS versions, and also on other clouds and vendor systems (we're hard bought into Datadog)
184 Views