High level architecture

Organization level

MONARC clients hosted on FO1 and FO2 push regularly stats about risk analysis to a local Stats Service instance ( This local Stats Service instance provides the required functionalities for the Global Dashboard of the MONARC clients. This step is the collection of stats and is local.


The collection of stats can be disabled per analysis.

The next step is the sharing of stats. Indeed, a company has the possibility to push stats from the local Stats Service to, for example,


The sharing of stats can be disabled per client.

The service behind is operated by CASES Luxembourg and aims to provide relevant data about the current cybersecurity trends, focused in the Luxembourg area.


The following diagrams presents the idea behind the decentralized nature of i Stats Service.

Scenario 1

Stats Service API interaction with MONARC

The Stats Service API (stats) is installed on the same server where the MONARC back office is deployed. Not on on a dedicated server. The server hosting the back office of MONARC is a good choice.


The Stats Service only communicates with the backend of MONARC thanks to its API.

The stats collection (from the FO to the stats node) can be triggered with a cron job.

The Stats Service instance is not exposed on the Web, this is not the finality of this internal component. The Front Office servers will simply contact the API of the Stats Service inside the environment.

However, if you want to expose this internal component, this can be done by setting X-Forwarded-Prefix in a VirtualHost (on the back office server). For example:

<VirtualHost *:80>

    DocumentRoot /var/lib/monarc/stats-service
    WSGIDaemonProcess statsservice user=www-data group=www-data threads=5 python-home=/home/ansible/.cache/pypoetry/virtualenvs/statsservice-KKeyDYL6-py3.8 python-path=/var/lib/monarc/stats-service/
    WSGIScriptAlias / /var/lib/monarc/stats-service/webserver.wsgi

    <Directory /var/lib/monarc/stats-service>
        WSGIApplicationGroup %{GLOBAL}
        WSGIProcessGroup statsservice
        WSGIPassAuthorization On

        Options Indexes FollowSymLinks
        Require all granted


    CustomLog /var/log/apache2/stats-service-access.log combined
    ErrorLog /var/log/apache2/stats-service-error.log

    <IfModule mod_headers.c>
        RequestHeader set X-Forwarded-Host ""
        RequestHeader set X-Forwarded-Prefix "/dashboardBO"

Then, in the configuration file of Stats Service, you will have to set the variable FIX_PROXY to True (see here)

Finally the service should be available at:

Another solution, probably cleaner, is to deploy a public instance of Stats Service and to push the stats from the internal Stats Service to the public one. With this solution you can select the stats you want to push and thus make public.

Scenario 2

Stats Service API interaction with MONARC

The Stats Service is installed on a dedicated server.

Scenario 3

Stats Service API interaction with MONARC

The user is simply connected to a MONARC front office deployed in a local Virtual Box instance. Stats Service (stats) is running next to MONARC in this virtual machine.

Important notes


In all scenario, locally collected statistics (in stats node) can optionally be shared with which is a global instance. It’s the same software. You can configure the global dashboard statistics sharing option in the General Settings / Sharing statistics view of your MONARC instance (see here).

However, stats must always be collected in your local Stats Service instance. This is required for the proper functioning of the global dashboard of your MONARC instance.


It is as well possible to run your own alternative to And then you can configure the variable REMOTE_STATS_SERVER of your local Stats Service instance with the address of your “global” instance.

Integration with external services


A Stats Service instance is able to query MOSP.