How to detect "Slow ACL" ?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-20-2022 09:08 PM
Hi everyone,
While making ATF on ACLs, it came under my radar a message similar to this one:
Slow ACL 62bbff831b2a68149dbcfc038d4ffbfb for the path record/sn_customerservice_case/read, time was: 21
I am trying to scope how wide the problem is on our instance. But this message is not displayed in the syslog, I could only find it in the Node Log.
Any idea how I would increase the visibility without having to dig into the Node Log? I want to see how bad the situation is, how often this happening and a list of ACLs to look at.
(and if anybody know what the '21' represents at the end of the message.... time in ms? )
Thank you
Philippe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-20-2022 09:56 PM
Hi, Try by adding query in ACL table as -
Sys_id IS 62bbff831b2a68149dbcfc038d4ffbfb
Thanks,
Sagar Pagar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-21-2022 01:41 AM
Hi,
Thanks but I am looking for the other potential sys_ids
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-20-2022 10:04 PM
Hi,
can you help us knowing what exactly are you testing using ATFs?
Regards
Ankur
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-21-2022 01:45 AM
Hi Ankur,
My ATF is challenging some roles like trying to update a record you are not supposed to have the right to.
Then in some situation, I can see the trace in my OP in the test results. This trace can be also found in the Node Log. And I am searching where else this happened without having to download all node logs and search into them.
Ultimately I would make an ATF than verifies that this trace does not appear in the syslog, but it's not in there.
Thanks