Title to group logs of the same context and easily find the wanted log

[fentes]

Hey,

we introduced NebulaLogger in our Org and are amazed by the easy use. So we use it in many different places. Unfortunately, this leads to the fact that we have a lot of logs and it is, therefore, difficult to find the right log only by the username and the time.

To keep the overview, we changed some lines and introduced a new field "Scenario". The Logger.saveLog() was cloned into Logger.saveLog(String myScenario)

I think this might be quite helpful for others as well ;)

[jongpie]

Hi @fentes - glad to hear you're finding Nebula Logger useful in your org! I could see possibly adding this type of functionality to the tool, but it also overlaps a bit with the functionality provided by using the tagging functionality, released in v4.6.0 (see screenshot below). Did you also consider using tags for your purposes? Tags are applied to the LogEntry__c records (not Log__c records like in your approach), and you can add multiple tags to each LogEntry__c, which is a bit more flexible than a single field on Log__c.

I'd love to hear if tags would also work for your purposes, or if there is definitely a need for something like your 'scenario' field. Let me know your thoughts!

[fentes]

Hey Jonathan,

thanks for your proposal! I tested the tagging. It doesn't fit our needs completely, because we are not interested in finding individuals entries but more in the whole log. We use the system to log business processes and want to know if the whole transaction was successful.

But we thought about a solution to combine both.
Currently, the naming of logs is coded into the framework, so updating the framework isn't easy anymore. But we can build a small trigger, to populate the tag up to the log itself. To have still a one-line save, we can create a new class that just looks like this

public void saveLog(String title) {
Logger.debug('Finish operation: '+title).addTag(title);
Logger.saveLog();
}

Then we are ready for updates again. Or you probably could extend the framework to tag log entries and logs.

[jongpie]

@fentes I've started looking into this a bit more, and I do like the idea of having a 'scenario' field on Log__c as shown in your screenshot, so I'm going to start working on adding this feature soon. I've logged a new issue for this - #217 - to keep track of the progress.

[jongpie]

@fentes I've created a new pull request - PR #218 - to officially add a new "Scenario" field to the Log__c object. If you have a chance to take a look at the PR, I'd love to hear your thoughts on this before I merge it. Let me know what you think!

[jongpie]

@fentes I've just released v4.6.10, which includes the new 'scenario' functionality - let me know if you need anything else!

[jongpie]

@fentes thanks for follow-up info! I think your approach makes sense as a way to give you what you need right now - I also agree that there is some value in having a field on Log__c that you can use in filters/list views (as opposed to tags are only on LogEntry__c). I have a few other enhancements that I need to wrap up over the next few months, but I'm going to also explore this item some more to see if it makes sense long-term to incorporate something into Logger.

Once I've had a chance to look into it further, I'll let you know if I ended up adding this natively to the tool!

[fentes]

Hey, @jongpie we discussed cases where we use the logger and came up with a similar idea. Potentially we will create a lot of logs per day and in most cases, they aren't really relevant to be stored for always. We looked into your Batch Deletion feature. But as far as we understand the feature does delete all logs after x days regardless of whether there is only info, an error, or in which context the log was created. What are your thoughts on setting up multiple retention rules depending on the scenario and included error?

For example:

• We have feature A which is very important. Logs of this feature must not be deleted at all.
• For Feature B we want to see the logs for 5 days. Then they can be deleted. Except there was an error. Then they should be deleted after 30 days.
• Feature C isn't really important. Logs should be deleted after 3 days.

All of the features have an identifier using the scenario field. And then there could be a custom metadata type where you can define a scenario, a retention day, and whether error logs should be skipped. For all logs without any scenario, you can have a default setting.

We probably will develop such a feature, but wanted to discuss it with you before. Maybe you say, that it might be relevant in general, then we can find some synergies.

[jongpie]

@fentes I love this idea - I've also had situations where I wanted to have more control over when certain logs are deleted, and I know others could greatly benefit from this feature too.

You are, of course, more than welcome to develop your own solution for this - but I think I'm going to try to incorporate this functionality directly into Nebula Logger. I've previously built another repo, Apex Validation Rules that uses 2 custom metadata types to provide very advanced configuration options, which I can repurpose for this functionality. I've created issue #226 to document this new feature idea.

[jongpie]

@fentes, this functionality is now finally available in a new a plugin called "Log Retention Rules", available as part of the v4.7.1 release. I've closed the original issue #226, but let me know if you or your team have any feedback on the new plugin!

[fentes]

Hey @jongpie thanks a lot. The new features sound really helpful and we're looking forward to using them.
However, we need to do some preliminary work first so we can update. Back when we added the scenario field, we had created a Logger.saveLog("my scenario") method and have used that everywhere since. Now with the new release, however, you had also added a method saveLog that expects a string. So for the time being no logs would be created. But to be able to use the releases in the future, we will adapt our classes to use your approach with setScenario("my scenario"). This will take some time though, so we can't give any feedback at the moment.

[jongpie]

@fentes no worries, thanks for the update! Hopefully you'll be able to make the necessary changes so that you can upgrade - if/when you do the upgrade, let me know if you have any feedback! And FYI, over the next few months, I will be making some more enhancements to how scenarios work, so the feature will hopefully become even better.

[jverelst]

Hi @jongpie, first I want to express my thanks for this wonderful package. I discussed building something like this myself with a colleague, then he found your package and we decided that this is way more advanced than anything we could've built ourselves :-).

This 'scenario' feature is something we are really interested in, because we have a lot of different features that we wanto to be able to distinguish. However, we would also like to be able to change loglevel on a scenario basis. It's now possible (and very handy!) to change the default loglevel that is being saved on a user/profile basis, but for us it would be great if it were possible to do this on a scenario basis as well. So for instance, we have 2 sets of REST classes:

• Set one is called 'UserManagement'
• Set two is called 'CaseManagement'

By default, we are only logging WARN+ on our production environment, but it would be great if we could configure that for the 'UserManagement' feature/scenario, we could have INFO+ logs. That would allow for very granular configuration, where we can group code into sets of classes that we can then toggle on-demand.

I'm not entirely sure that this is a feature that's part of this PR, would it be possible to extend the use of scenarios into the custom metadata settings?

[jongpie]

HI @jverelst - I'm glad to hear you're using Nebula Logger! I've tried to make it as advanced & robust as possible so others don't have to build their own logging tool.

As far as your idea, I think what you're asking for is feasible for a future release/PR, but I just want to be sure that I understand the concept. So, assuming the current user has a Logging Level == 'WARN', then in your production org, this code would only save the WARN log entry...

Logger.info('an example INFO log entry - this will not save because the user has Logging Level == WARN');
Logger.warn('an example WARN log entry - this will save since it matches the user Logging Level');
Logger.saveLog();

As a future enhancement, I could add a new custom metadata type to control the Logging Level for each Scenario, regardless of the current user's logging level. If you were to configure the scenario 'UserManagement' with Logging Level = 'INFO', and then ran this code, all of the log entries would be logged (even if the user still has Logging Level == 'WARN')

Logger.info('some log entry created BEFORE specifying a scenario - it does not meet the user Logging Level, but does meet the hypothetical logging level of the scenario');
Logger.setScenario('UserManagement'); // Assumption - there would be a custom metadata type where you configure the logging level for this scenario
Logger.info('some log entry created AFTER specifying a scenario - it does not meet the user Logging Level, but does meet the hypothetical logging level of the scenario');
Logger.saveLog(); 

In this example, the first log entry would not be saved because the scenario is specified after the log entry has been added - so it will be very important to call Logger.setScenario() as early as possible to ensure that all relevant log entries are saved. Let me know if this limitation sounds ok to you - if so, then I can work on adding this functionality in a future release.

[jverelst]

Hi @jongpie, this is indeed exactly the behavior that we are seeking! Of course, you would have to use Logger.setScenario() at the start of the process, but that's not that hard considering we know which code entrypoints are used within different scenarios. And this would give us the flexibility to enable more detailed logging on specific parts of the codebase without overflowing the system with logs from all other scenarios / features.

[jongpie]

Hi @jverelst - thanks for the feedback (and sorry for the delay in responding!). That sounds good to me - I've logged issue #235 to document this enhancement. I'll look into implementing in sometime in the next few weeks.

[jongpie]

Hi again @jverelst - I've created pull request #237 to add this functionality. It's still a work in progress, but I think the basic functionality is now there: a new custom metadata type called LoggerScenarioRule__mdt is included that lets you configure the logging level for a specific scenario. I'm planning to include a few other unrelated changes in this PR, but I'd love to hear any feedback you have on this PR.

If you'd like to test the functionality yourself, you can install this beta package in a sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015l2vQAA

[jverelst]

@jongpie I've tested this version in one of our sandboxes and indeed it works as expected, very nice, thanks!! I do have some feedback on the PR, but I will post the details on PR #237