mikrotik-exporter icon indicating copy to clipboard operation
mikrotik-exporter copied to clipboard

Feature request: stay connected so the logs aren't spammed

Open wolph opened this issue 5 years ago • 4 comments

Right now the collector seems to login/logout continuously. Would it be possible to simply stay logged in so you don't get logs filled with connected/disconnected messages?

wolph avatar Dec 16 '19 01:12 wolph

This is a bit more invovled than reusing the existing connection. I've done a small test with connection re-use, and its incredibly easy to break. In this case i've set it so the RouterOS API Client is created and 'stored' in the collector struct, re-used if it is not nil. If two requests are made to the collector at the same time (or whilst another Collect is in progress) it will cause the second request to 'hang', and no more requests will be successful to that device.

There are few ways I can think of solving this

  1. Create a 'queue' per device, where all requests are handled in FIFO, this also would require some way of tracking which queue entries are for which HTTP request
  2. Hold a lock whilst the connection is in use. How the lock is handled needs to be considered, and timeouts need to also be implmented for the commands via the API
  3. Implement the 'multiple command' functionality in the Mikrotik API
  4. Seperate out the Collect 'process' from the scrape - this isn't necisarily a great idea, as freshness of the collect needs to be considered

I'm leaning towards the third option my self.

welbymcroberts avatar Dec 31 '19 16:12 welbymcroberts

Hmm, that's harder than I had hoped. I was somehow assuming that the requests would be fast enough that a simple threading.Semaphore would be enough to solve those issues.

Effectively:

semaphore = threading.Semaphore()

# Do something
if semaphore.acquire(timeout=10):
    # Execute the code
else:
    # Timeout, reconnect maybe?

wolph avatar Dec 31 '19 17:12 wolph

It's probably something that should be implemented in the upstream Client API Library either via a long lived connection with a health checking mechanism and reconnect logic. I think even with the multiple commands call it would still get the connected/disconnected messages in the log file.

nshttpd avatar Feb 04 '20 02:02 nshttpd

While from a security perspective not great the fix for me was excluding the account topic:

image

RickDB avatar May 30 '20 12:05 RickDB