You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a production environment, debug logging isn’t something that’s desirable all the time; given the performance considerations associated with rules, it would not be prudent to have it continuously enabled.
Given this let's do a few things
Establish a debug logging capability like that described by Auth0 that depends on a configuration setting which we would leave off in production normally. Maybe we want to get fancy and instead of storing a boolean in configuration we store a date/time. Then we emit debug logs if the date/time is older than the one in configuration. This way we can avoid accidentally leaving debug logging on.
Establish a new logging capability that emits logs out of Auth0 webtask so they can make it to MozDef. I contacted Auth0 support to find out what the recommended way to do this is and they don't have an intentional facility for this but said that the notion of emitting them ourselves, as long as we're not blocking, should work fine. So I imagine the way to do this would be
Use the aws-sdk combined with AWS credentials in configuration to send the log message via SNS to a topic.
Setup a lambda consumer on that topic which takes the log message, wraps it in a MozDef message format and drops it in SQS
Currently we use
console.log
liberally in our rules.The Debugging Best Practices page says
Given this let's do a few things
configuration
setting which we would leave off in production normally. Maybe we want to get fancy and instead of storing a boolean inconfiguration
we store a date/time. Then we emit debug logs if the date/time is older than the one in configuration. This way we can avoid accidentally leaving debug logging on.aws-sdk
combined with AWS credentials inconfiguration
to send the log message via SNS to a topic.Here's an example of something tangential but related for splunk
The text was updated successfully, but these errors were encountered: