We're on SQL Server 2016, yes?
Don't use Profiler and Trace Events. They are old school. Worse yet, filtering on them is horrible. Even though you apply a filter (only look at this query, or this table, as you're asking for), Trace still captures every single call, using all the memory and CPU necessary to capture all the calls, then filters after the fact.
Instead, use Extended Events. You're on SQL Server 2016. You're probably using functionality written since 2008R2, right? Well, Extended Events is how you have to monitor that functionality. There's no reason to not use it to monitor queries, etc.. In fact, there are lots of good reasons to use it. Filtering is just one. Instead of filtering after capture, Extended Events operates within the OS of SQL Server and filters before capture. The more granular you make your filters (just this database, just this object), the lower the load it actually places on the system.