Add more verbosity to task lock exception?

[a3rosol]

Hi, currently when one runs huey consumer with the -q option and a task lock can't be aquired, the following message is printed:
[2023-08-01 09:36:33,816] WARNING:huey:Dummy-2222:Task 1548ef3c-89e6-472e-9282-9937b3f80385 not run, unable to acquire lock.
Would it be possible to add either the task lock name or the function name to the message so one knows which lock couldn't be aquired? Without the rest of the huey logs, it's really hard to find out which lock it was otherwise.

Additionally, you expose

       huey.pending_count()
       huey.scheduled_count()
       huey.result_count()

For metric logging purposes I'd like to know how many tasks are currently running as well. I'm currently using len(huey._tasks_in_flight) but as you can imagine accessing a protected member doesn't feel right. I thought about using signals, but that seems like overkill. Any chance you could expose the protected member like the other metrics?

[coleifer]

For metric logging purposes I'd like to know how many tasks are currently running as well. I'm currently using len(huey._tasks_in_flight)

The consumer is aware of how many tasks are currently in-flight, but that state is local to the consumer process and not available to (e.g.) the application...

[a3rosol]

Yes, but it would still be a useful metric to have. If I have 5 consumers and one is pretty much underutilized I'd like to know so I can scale back. Or if there are 5k tasks in flight and an additional 15k pending with more and more coming in, another consumer could be spun up