Guide d'installation de DigDash Agent

Modifié par Aurelie Bertrand le 2025/12/18 14:51


Ce document présente l’installation et la configuration de l’agent DigDash et de ses principaux composants.

Il faudra ensuite installer configurer le chatbot. Seul OpenWebUI est supporté pour l'instant. Consultez la page Guide d'installation d'Open Web UI pour plus de détails.

Installation du serveur Agent

Prérequis

  • Un conteneur de servlets compatible Jakarta EE 9+, tel que Tomcat 10 ou Jetty 11
  • Java 17

Décompressez l’archive d’installation de DigDash Tomcat 10 et placez le fichier /add-ons/agent/digdash_agent.war dans le dossier webapps de Tomcat.

Création des logs

  1. Créez un fichier log4j2_agent.properties dans /etc/digdash avec la configuration suivante :

    ###################################
    # Log4j2 Status
    ###################################
    status=error
    name=PropertiesConfig
    ###################################
    # Rolling File Appender
    ###################################
    appender.rolling.type=RollingFile
    appender.rolling.name=RollingFile
    appender.rolling.fileName = /var/log/digdash/digdash_agent.log
    appender.rolling.filePattern = /var/log/digdash/digdash_agent-%i.log.gz
    appender.rolling.layout.type=PatternLayout
    appender.rolling.layout.pattern = %d %-5p [agent] [%t] (%F:%L) - %m%n
    appender.rolling.policies.type=Policies
    appender.rolling.policies.size.type=SizeBasedTriggeringPolicy
    appender.rolling.policies.size.size=200MB
    # Rollover strategy
    appender.rolling.strategy.type=DefaultRolloverStrategy
    appender.rolling.strategy.max=15
    ###################################
    # Root Logger
    ###################################
    rootLogger.level=info
    rootLogger.appenderRefs=rolling
    rootLogger.appenderRef.rolling.ref=RollingFile
    ###################################
    # Application-specific Logger
    ###################################
    logger.app.name=com.digdash
    logger.app.level=info
    logger.app.additivity=false
    logger.app.appenderRefs=rolling
    logger.app.appenderRef.rolling.ref=RollingFile

Cette configuration stocke les logs dans le fichier /var/log/digdash/digdash_agent.log et archive les anciens logs dans le dossier /var/log/digdash/. Vous pouvez ajuster la propriété logger.app.level pour modifier le niveau de verbosité des logs de l’application web.

  1. Ajoutez la ligne suivante dans /etc/digdash/digdash.properties pour que DigDash puisse lire la configuration des logs :

    agent.ddlog4j.properties.file=/etc/digdash/log4j2_agent.properties

Configuration LLM

L’application web prend en charge les modèles d’OVH Cloud. Il est recommandé d’utiliser le modèle "Llama-3.3 70b".
D’autres modèles sont disponibles dans le catalogue OVH : https://endpoints.ai.cloud.ovh.net/catalog.

  1. Ajoutez l’URL de l’API LLM dans /etc/digdash/digdash.properties :agent.llm.baseurl=https://llama-3-3-70b-instruct.endpoints.kepler.ai.cloud.ovh.net/api/openai_compat/v1
  2. Générez une clé API depuis OVH Cloud en suivant ce guide : https://help.ovhcloud.com/csm/en-public-cloud-ai-endpoints-getting-started?id=kb_article_view&sysparm_article=KB0065403
  3. Ajoutez votre clé API dans /etc/digdash/digdash.properties :

    agent.llm.apikey=<API_KEY>

Configuration de l’application

  • Configurez le serveur backend pour correspondre à votre environnement dans /etc/digdash/digdash.properties :
agent.digdashserver.baseurl=https://<digdash.url.externe>
agent.digdashserver.domain=ddenterpriseapi

L'url du serveur Digdash corresponde à l'adresse publique d'accès à Digdash.

L’application web concaténera ces deux propriétés pour former l’URL complète du serveur backend (ex. : http://localhost:9080/ddenterpriseapi).

Déploiement

  1. Déployez le serveur Tomcat.
  2. Après le démarrage du serveur, exécutez la commande suivante pour vérifier que le serveur agent fonctionne :

    curl http://localhost:8080/digdash_agent/actuator/health

    La réponse attendue est :

    {
     "status": "UP"
    }
  1. Vérifiez les journaux de démarrage dans /var/log/digdash/digdash_agent.log pour détecter tout avertissement ou erreur indiquant une configuration manquante.

Installation de ChromaDB

L’agent utilise ChromaDB, une base de données vectorielle, pour effectuer des recherches sémantiques sur les données des cubes DigDash.

Prérequis

  • Serveur Linux
  • Accès root au serveur

Installation

  1. Créez le dossier d’installation :

    sudo mkdir /opt/chroma
    sudo useradd -m -s /bin/bash chroma
    sudo chown chroma:chroma /opt/chroma
  2. Accédez au dossier d'installation:

    sudo su - chroma
    cd /opt/chroma
  1. Créez un fichier bash "install-chroma-cli.sh" via `nano install-chroma-cli.sh` en copiant-collant le script suivant:

    # ----------------------------------------------
    # Chroma CLI Installer Script
    # Usage:
    #   curl -sSL https://raw.githubusercontent.com/chroma-core/chroma/main/rust/cli/install/install.sh | bash
    # ----------------------------------------------
    REPO="chroma-core/chroma"
    RELEASE="cli-1.1.10"

    OS=$(uname -s)
    ARCH=$(uname -m)
    ASSET=""

    case "$OS" in
      Linux*)
       ASSET="chroma-linux"
        ;;
      Darwin*)
       if [ "$ARCH" = "arm64" ]; then
         ASSET="chroma-macos-arm64"
       else
         ASSET="chroma-macos-intel"
       fi
        ;;
      MINGW*|MSYS*|CYGWIN*)
       ASSET="chroma-windows.exe"
        ;;
      *)
       echo "Unsupported OS: $OS"
       exit 1
        ;;
    esac

    DOWNLOAD_URL="https://github.com/${REPO}/releases/download/${RELEASE}/${ASSET}"
    echo "Downloading ${ASSET} from ${DOWNLOAD_URL}..."
    curl -L "$DOWNLOAD_URL" -o chroma

    chmod +x chroma
  1. Exécutez le script "install-chroma-cli.sh" pour installer l’interface en ligne de commande Chroma (Chroma CLI) :

    install-chroma-cli.sh
  2. Créez le fichier de configuration de Chroma "config.yaml" :

    #################
    # OpenTelemetry #
    #################
    open_telemetry:
      service_name: "chroma"
      endpoint: "http://127.0.0.1:4317"
      filters:
        - crate_name: "chroma_frontend"
          filter_level: "trace"
    ########################
    # HTTP server settings #
    ########################
    port: 8000
    listen_address: "127.0.0.1" # Accept only local requests
    max_payload_size_bytes: 41943040
    cors_allow_origins: ["*"]

    ####################
    # General settings #
    ####################
    persist_path: "/opt/chroma/data"

Notez que Chroma n'écrit pas de log dans la sortie standard si la configuration "Open Telemetry" n'est pas donnée.

Dans notre installation, nous ne comptons pas mettre en place un serveur Open Telemetry collectant des métriques.  
Cela génère un log d'erreur toutes les minutes quand Chroma appelle le serveur car non disponible.

D'après la documentation OpenTelemetry, nous pouvons configurer la variable d'environnement OTEL_METRIC_EXPORT_INTERVAL pour déterminer la périodicité des appels d'export de métrique.
Ainsi, en donnant une valeur très élévée, le service sera "désactivé" en attendant le support de la variable OTEL_SDK_DISABLED dans l'implémentation rust d'OpenTelemetry.

  1. Désactivez la configuration OpenTelemetry en ajoutant la variable d'environnement OTEL_METRIC_EXPORT_INTERVAL suivante :

    echo -e "\n### Chroma Configuration\nexport OTEL_METRIC_EXPORT_INTERVAL=31556952000 #one year in milliseconds" >> ~/.bashrc
    source ~/.bashrc
  2. Augmentez la limite « soft » et « hard » du nombre de fichiers ouverts à au moins 65 536.
    Chroma doit pouvoir ouvrir de nombreux fichiers sous forte charge. Si ces limites sont trop basses, il pourrait ne pas réussir à ouvrir la base de données et l’application risquerait de ne plus fonctionner.
    Vous pouvez vérifier les limites actuelles avec :

    ulimit -n    # soft limit
    ulimit -Hn   # hard limit

    Si la limite est trop basse, alors vous pouvez augmenter temporairement la limite pour votre session ssh avec

    sudo ulimit -Hn 65536
    ulimit -n 65536

    ou appliquer de manière permanente les changements en modifiant les limites de securité du serveur `/etc/security/limits.conf`:

    sudo nano /etc/security/limits.conf

    Et en ajoutant les nouvelles limites de fichiers ouverts par processus pour l'utilisateur chroma:

    chroma soft nofile 65535
    chroma hard nofile 65535
  3. Enfin, exécutez la commande suivante pour déployer le serveur :

    ANONYMIZED_TELEMETRY=False ./chroma run config.yaml >> chroma.log 2>&1 &

Chroma est écrit en Rust, vous pouvez donc ajuster la verbosité des logs en définissant la variable d’environnement RUST_LOG=debug.

  1. Exécutez la commande suivante pour vérifier le bon déploiement du serveur:

    curl http://localhost:8000/api/v2/heartbeat

    La réponse devrait ressembler à:

    {"nanosecond heartbeat":1760109567965688154}

Configuration des paramètres du serveur DigDash

Pour configurer les paramètres du serveur DigDash, depuis le menu Configuration, allez sur la page Paramètres serveur > Paramètres supplémentaires > Intelligence Artificielle.

Dans la section Agent, cochez Activer la fonction Agent afin d'activer un ordonnanceur qui intègre périodiquement de nouveaux cubes et stocke les vectorisations dans la base Chroma. Une fois l'option activée, les paramètres suivants sont effectifs.

Paramètre Description
Fréquence en secondes de la vectorisation des cubes dans la base de vecteursDéfinit la fréquence d’exécution de l'ordonnanceur. Ajustez selon la fréquence de reconstruction des cubes. La valeur minimale est de 1 seconde.
Il est recommandé d'utiliser une valeur de 60 secondes.
URL de base du modèle de vectorisation

L’Agent prend actuellement en charge uniquement les modèles d’OVH. Nous recommandons le modèle BGE-M3 : https://bge-m3.endpoints.kepler.ai.cloud.ovh.net.

Clé API du modèle de vectorisationVous pouvez réutiliser la clé API utilisée pour le LLM.
URL de base du stockage des vecteursDéfinissez l’URL de base vers la base de données ChromaDB : http://localhost:8000.
Clé d'environnement spécifique (prod, test ou dev)ChromaDB stocke les vectorisations des cubes dans différentes "collections". Ce paramètre préfixe toutes les collections ChromaDB avec la valeur spécifiée (ex. : prod, test, dev). Utilisez-le si vous souhaitez utiliser la même base ChromaDB pour différents environnements.
Délai d'expiration du stockage des vecteursValeur par défaut : 30 secondes.  Après ce délai, la requête est réessayée plusieurs fois avant d’échouer.
Forcer l'initialisation du stockage des vecteurs    Cochez cette case pour effacer complètement la base pour l’environnement spécifié.
Liste des rôles à vectoriser

Par défaut, tous les rôles sont vectorisés.
Pour limiter l’Agent à certains rôles, listez les identifiants des rôles séparés par des virgules (par exemple : Retail_2d6e0f1e, R_D_7b55a031).

Liste des modèles à vectoriser

Par défaut, tous les modèles de données sont vectorisés.
Pour limiter l’Agent à certains modèles, listez les identifiants des modèles de données séparés par des virgules (par exemple : 761a667955c84f834bb2950996f93e1fv, c99c1c9fadd5e4ceafc954c4fb7c1067).

Liste des hiérarchies à vectoriser

Ajoutez le nom des hiérarchies temporelles que l’Agent doit interpréter. L’Agent détectera les filtres temporels dans l’entrée utilisateur et trouvera la correspondance la plus proche parmi les membres des hiérarchies spécifiées.
Pour retrouver la liste de vos hiérarchies temporelles, allez dans le gestionnaire de hiérarchies du Studio. Consultez la page Gestionnaire de hiérarchies.

Si le champ est vide, aucune hiérarchie ne sera prise en compte.

Une fois cette installation terminée, vous pouvez passer à l'installation d'Open Web UI.

Pour en savoir plus...