This topic was automatically generated from Slack. You can find the original thread here.
I want to create a component that manages centralized logging, ideally that can be consumed from any workflow, ideally as simply as logger.log (etc). The logging target in this case will probably be CloudWatch but may change over time, which is one reason for centralizing it. The best solution I found so far is to publish custom code to a private node repo. Is there a better solution?
You mean publishing a private action to your workspace, yeah?
That’s the best solution
I read the documentation and watched the video, but I guess I’m missing something. I now understand how to create a component that can be used as a step from any workflow in my account.
However, my goal is to (essentially) provide a replacement for console.log(). I don’t understand how that reusable component would export a function e.g. logger.log() that other steps can use.
For reference, when I tried defining a step in my current workflow that exports functions, they were not part of $return_value.
I was thinking you wanted something like export a log to somewhere external like CloudWatch
You could add essentially two props:
And then after adding the step to your workflow, you could export that log every time it executed
The purpose is for observability: So I can track important actions in Pipedream to diagnose issues and alert on them.
As far as I understand console.log in Pipedream, I’d have to select a specific event (instance of a pipeline running) and look at the logs for each event. But perhaps there’s a better way?
The purpose is for observability: So I can track important actions in Pipedream to diagnose issues and alert on them.
That should help for observability, you can tag those logs with the workflow name/id or anything
There isn’t a logging sink in Pipedream, we provide Email and Slack notifications on errors
But that is a common ask
Yeah; I’m essentially trying to create a logging sink that can be used very much like a logging framework would be in enterprise code.
With the approach you describe, wouldn’t each step need to return any information to be logged, and after each step, I’d need to add a logging step to handle any loggable output?
That’s just a feature request in our public repo
Almost 3 years old 
With the approach you describe, wouldn’t each step need to return any information to be logged, and after each step, I’d need to add a logging step to handle any loggable output?
It could work both ways — you can output something from the step or just have a hardcoded text
Are you thinking of adding in between every step?