6

I've found these two excellent projects:

that use Platform Events for logging and include a client to view the logs.

We are thinking of using this mechanism (across multiple managed package namespaces), but want to make sure we have grabbed all the good ideas that are already out there before we put ours together.

So if you know of other open-source logging frameworks we should look at, please post links. Also, any gotchas?

PS

Anyone fed Platform Events to e.g. https://www.loggly.com/ or https://www.datadoghq.com/log-management/?

PPS

I recently (March 2021) came across this Nebula Logger for Salesforce.

7
  • I can't contribute an answer since I've not considered looking for one. Use of platform events for logging an interesting choice; on the one hand you can ensure that logged details are captured regardless as to success of the current session/request/transaction (given that platform events are not part of the current transaction). On the other, there are specific daily limitations on how many events you can dispatch. – Phil W Jan 20 '20 at 11:20
  • We have a simple object we use to capture customer user facing "log events" from our managed package code, which is (of course) entirely proprietary but able to be viewed, searched and managed using standard Salesforce UX functionality. – Phil W Jan 20 '20 at 11:22
  • Thanks for these points @PhilW; will head-scratch a bit more about the daily limits. Always been put off using a normal custom object because of rollback. – Keith C Jan 20 '20 at 11:39
  • 1
    we use the andyinthecloud framework with many "enhancements" to the methods in his Log class; we also use a trigger on the platform event to save persistently into a Log__c sobject. The one tricky bit was when the log-in-memory started eating up Heap so we implemented a log flusher within Log__c. If you want to discuss more, I suggest going to chat – cropredy Jan 20 '20 at 19:46
  • 1
    Years ago long before Platform events even existed I played around with callous to external logging APIs like loggly but it never worked out because of salesforce governor limits. I also planned to track usage of our managed ISV apps by sending track marks from pages classes etc. – Robert Sösemann Oct 6 '20 at 21:01
3

The other idea I would throw in there is to make the logging implementation a plug-in.

In my own spin on this, I have a unified Logger class where each call to log includes an identifier of which Component it is e.g. I log like this:

Logger.log(LoggingLevel.DEBUG, 'My Component', 'A message');

And then I have a custom metadata record which sets the logging level and implementation per component e.g. 'My Component' might be set at LoggingLevel.DEBUG use System.debug as the implementation. While 'My Integration' might use Platform Events.

The different implementations may be more appropriate for different circumstances e.g. in a unit test, System.debug is really nice and simple because you can see it right there in the log with no extra work. At run-time in production, Platform Events are great.

Also, if you're installing into unknown environments, you can use a plug-in to make it fit e.g. We are a consultancy, and maybe our customer already has a Log__c or Log__e object. No problem, we write a plugin just for them which fits in with their existing code/config.

1
  • 1
    Hi Aidan, Good points. Yes, there will be a simple log API and we will be able to add more than one "back end". Presently thinking that "My Component" will just be the class name discovered from the stack trace. – Keith C Jan 20 '20 at 11:37
1

Not open source but internally we use a logging framework which in how it is used follows the pattern in the answer from Aidan. We are currently implementing forwarding of log messages to ELK. Considerations:

  • I would love to simply plug a Mulesoft API in here and use that to subscribe to the log message platform event, transform and forward to ELK. However, this would be a CometD based subscriber and therefore consume the platform governor limit on delivered platform events to all CometD subscribers including empApi.
  • An Apex trigger subscriber however would be limited by its Apex transaction limits but otherwise have little impact on other logic on the platform.
  • The trigger needs to be ready to handle the up to 2000 platform events delivered in one transaction and also be ready to handle platform events up to 1MB in size.
  • Apex CPU time limit becomes a limiting factor - in my tests - only when checking the governor limits during execution which seems to be an expensive operation. But transforming many platform events into JSON to send to ELK is not CPU heavy. Heap size consumption needs to be controlled though.
  • The fallout to ELK happens in a future because even in a trigger that is a platform event subscriber we cannot synchronously do Http Callouts. So, the other limiting factor is the number of futures that we can launch.
  • If not all platform events can be processed we can use setResumeCheckpoint to control which platform events are delivered again in another transaction.

The code is currently in testing and review.

1
  • Thanks for posting Magnus, and including the care needed to stay within governor limits. – Keith C Mar 23 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.