Are there any statitics about activity somewhere in Zammad, a log file or in the ruby console?
What I am looking for is the number of currently active agents. So logged-in users that have actively worked on a ticket in the past 30 or 60 minutes.
Idealy there would be even more statistics like opened tickets. Not the tickets with status “open” but those that are opened/viewed by an agent.
The reason is, that I would like to see a direct comparsion of users/agents active and the server load and use of ram.
I’ve not found that opened ticketes by agents are logged.
But did you check the database?
there might be some tables which might help you further.
The tickets<=>ticketArticles table could show you how many agents worked on a ticket in a timeframe
I also see the karmaActivityLogs<=>karmaActivity which seems contain log many events that could happen on a ticket;
if you check my grafana topic (Grafana dashboards), you can download some queries. You probably could expand on the messages per ticket query to figure this per agent per ticket.
In general i find it very hard to find where i could gather good statistics from the usage and tickets. But this is probably a lack of knowledge on zammad.
It would be nice if there was some documentation on this, besides the general reporting.
Hi @olafbuitelaar
Thanks for sharing. We are already using grafana at this instance and I will have a look at the options with ES.
@MrGeneration when does a session become inactive? For example x minutes after the last user input?
Can I separate the current active sessions in agents sessions and regular/client users?
And a last question where maybe someone has an idea: We are running Zammad on Debian 10 with nothing else on that server as Zammad, Elasticsearch and Grafana (influx DB). The server has 2 cores and 4 GB RAM. Only 2-3 agents are active.
Free RAM ≈ 250 MB
Available RAM ≈ 950 MB
Used SWAP ≈ 300 - 350 MB
@ecomsilio another thing that occurred to me, you could check the histories table, this contains all interactions, but is in a bit hard format to gather statistics from. but you could gauge some numbers…of changes per day for example.
If you have any interesting grafana dashboards/ideas to share…i’m eager to hear them.
In regards of the swap, i’m not sure if i could answer that since it’s a complex subject. In the basics the amount being swapped is controlled with the kernel parameter “vm.swappiness” you could try lowering it, or 0 to disable swap. But this requires some more testing and research on your end.
There are many tools that could get the amount of swap per process (just google for; get swap size per process). I think all just read /proc//status or /proc//stat, which you could do manually for the zammad processes.
My install is about the same size, maybe even smaller, but to give you an idea;
NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
corp-zammad_zammad-railsserver.1.yqyl6ywwn6sfn73mbymbsret5 0.01% 1.235GiB / 178.9GiB 0.69% 5.07GB / 1.37GB 67.9MB / 0B 11
corp-zammad_zammad-scheduler.1.tkvm7uxke46hdc0z1860d0azs 2.27% 820.2MiB / 14.53GiB 5.51% 1.47GB / 236MB 19MB / 0B 11
corp-zammad_zammad-websocket.1.wa623enmwcvvkne2p2wvz5lyu 0.08% 191.4MiB / 14.53GiB 1.29% 1.61MB / 23.2MB 2.27MB / 0B 2
corp-zammad_zammad-nginx.1.pf6aufhwvda4on4vc7qm2hpat 0.00% 10.26MiB / 94.26GiB 0.01% 1.48GB / 1.22GB 65.5kB / 62.5kB 17
corp-zammad_zammad-postgresql.1.xprbbyd0vxfnn6ejr3iw5sk4g 0.09% 539.9MiB / 94.26GiB 0.56% 418MB / 10.8GB 37.2MB / 18.9kB 48
orp-zammad_zammad-memcached.1.p50l0d1ahgvk7kdzpg531kgpr 0.07% 48.73MiB / 176.9GiB 0.03% 119MB / 1.3GB 0B / 0B 10
corp-zammad_grafana.1.jghy07i288gdpucowrl71wfh5 0.09% 35.27MiB / 178.9GiB 0.02% 38.2MB / 37MB 75.3MB / 0B 23
so sort of quick total is about 2.5GB of RAM
So far I have found out that the SWAP is created by Elasticsearch and not Zammad. I will try to find out some more details. I looks like ES is just caching some queries. Especially since used RAM is less than 2.5 Gb of the total available 4 Gb.
indeed ES is memory hungry, it uses about 1.4GB on my install. Maybe you can host your ES on another machine. Or maybe you can downtune the java heap sizes; Heap: Sizing and Swapping | Elasticsearch: The Definitive Guide [2.x] | Elastic
I believe technically ES is not required for zammad, but it is used for it’s indexing capabilities and thus optimizes searches and maybe other data retrieval.
Disabling Elasticsearch will also remove functionality options like reporting or advanced search.
Beside of that, swapping also is a topic depending on the system.
The keyword to look for here is swapiness which decides on how fast your system will start to swap.
But yes, limitting Zammads memory usage may be relevant too!
Edit:
As far as I’m aware this should happens within minutes in worst case.
Should depend a bit on how the session is ended. To be honest, I’m a bit lazy to search in the code right now. It shouldn’t be more than 5 minutes though.
