[asterisk-dev] Logging and multi-tenancy

[Luke Escudé]

In our case, we've managed to turn Asterisk into a Docker container, so we can scale up/out as much as needed.

Interestingly, after running about 500 containers in production (500 asterisk instances) we've found that there's a lot of untapped power in the smaller containers, so we ended up designing our PBX web portal and our dial plan to be multi-tenant.

So, effectively, we can stick about 20 customers (roughly 100 to 400 SIP endpoints total) on a single Asterisk docker container without breaking a sweat.

The main issue now is trying to filter the real-time console output - We don't give customers access to any of that of course, just filtered logs and events via our web portal, which is permissions-based - so that a technician can diagnose a possible call flow failure without having to grep through tons of information.




Luke Escudé

Owner, CEO


972.600.1150

support at primevox.net

Schedule a meeting!<https://outlook.office365.com/owa/calendar/PrimeVOXCommunications@primevox.net/bookings/>


View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering>
View the PrimeVOX Status Page here<https://status.primevox.net/>
________________________________
From: Jaco Kroon <jaco at uls.co.za>
Sent: Wednesday, January 18, 2023 1:31 AM
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>; Luke Escudé <luke at primevox.net>
Subject: Re: [asterisk-dev] Logging and multi-tenancy


Hi Luke,


On 2022/12/23 18:48, Luke Escudé wrote:
So, it's possible to achieve multi-tenancy in Asterisk with well-designed dial plan. By multi-tenancy, in terms of Asterisk, I mean each "customer" has their own separate dial plan, and each customer cannot "see" another.

As long as each "customer" has their own "endpoint" details (for whatever protocol they use to connect), yes, this is technically possible.  There are other risks associated, eg, if you give them access to AMI or even to the CLI ... how do you control data visibility?  This just gets very, very risky.


Given that a well tuned asterisk instance can use sub 100MB of RAM ... I don't see the problem with running an asterisk instance per tenant.  Eliminates most of the above concerns, and if you do it right, pretty much all of the issues just goes away.  The one serious downside is that you need to bind each one to a different IP ... which is also not a major problem, one idea around this is to use a SIP proxy to dispatch to the correct "private" IP based on the registered to realm.

However, when it comes to looking at the asterisk CLI/console, you see all the calls flowing across all dial plans, which can be a lot to look at.
Correct.

What is the possibility of adding some kind of "tenancy filtering" to CLI logging?
Extremely unlikely.

Example: At the beginning of a dial plan call, let's say exten => s, we set LoggingTenancy(customer_id), then all of the subsequent log messages are visible in the CLI only if you run the "logging view tenant (x)" or something like this.

That would make it easier to diagnose call issues on high-volume systems.

Agreed.  We generally use the full log.  So in logger.conf:


full => notice,warning,error,debug,verbose(4),dtmf,fax


Now each call will have a C-?????? tag associated with it.  So after the call has completed, find the C-????? tag (You can for example use your LoggingTenancy idea here, but something like Verbose(TENTANT=?????, CLI=${CALLERID(full}, DST=${EXTEN}) - this will give you something to grep for in the full log to find C-??????, then grep C-?????? full.

I, personally, do not have the ability to implement this, but I wanted to put it out there.






Luke Escudé


972.600.1150

support at primevox.net<mailto:support at primevox.net>

Schedule a meeting!<https://outlook.office365.com/owa/calendar/PrimeVOXCommunications@primevox.net/bookings/>


View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering>
View the PrimeVOX Status Page here<https://status.primevox.net/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230118/00ac9697/attachment-0001.html>