Alors que de plus en plus d'équipes adoptent des plateformes de recherche cloud-native ou explorent de nouvelles alternatives à Apache Solr, de nombreuses entreprises se retrouvent prises entre deux feux : elles disposent de déploiements Solr essentiels à leur activité, trop anciens pour être mis à niveau rapidement, mais trop importants pour être abandonnés. Et lorsque cela se produit, une question prend soudainement toute son importance :

Surveillance d'Apache Solr
Car la vérité est simple : l'ancienne version de Solr peut encore être extrêmement performante, mais seulement si vous considérez la surveillance comme une priorité absolue plutôt que comme une simple formalité.

Pourquoi tant d'entreprises utilisent-elles encore d'anciennes versions de Solr ?

On pourrait facilement penser que seules les grandes entreprises utilisent des versions obsolètes, mais en réalité, c'est aussi le cas des start-ups, des entreprises SaaS de taille moyenne, des éditeurs numériques et même des plateformes de commerce électronique. Pourquoi ?

Quelques schémas courants :

1. Le schéma de recherche est devenu trop personnalisé

Solr est flexible – ce qui constitue à la fois son principal atout et la raison pour laquelle les mises à jour sont souvent retardées. Dès lors qu’une équipe personnalise en profondeur le schéma, les analyseurs, les tokeniseurs ou les gestionnaires de requêtes, la mise à jour s’apparente davantage à un « projet archéologique ».

2. Le système « fonctionne tout simplement » et personne ne veut y toucherSi vous avez déjà hérité d’un ancien cluster Apache Solr, vous connaissez déjà cette vérité que personne n’ose vraiment dire à voix haute : faire tourner Solr en production, c’est un peu comme continuer à rouler avec une voiture de collection. 

Quand tout est parfaitement réglé, le système fonctionne sans accroc : rapide, fiable, éprouvé. Mais dès qu’un élément se dérègle ? La latence de recherche grimpe en flèche, l’utilisation de la mémoire JVM se comporte de manière étrange, et vous vous surprenez à vous demander : « C'est quoi déjà, l'âge de cette instance Solr ? »

C'est plus courant que ne veulent bien l'admettre la plupart des ingénieurs. Si le moteur de recherche fonctionne bien et que les clients sont satisfaits, le coût d'un changement semble trop élevé. Pourquoi prendre le risque d'introduire des incohérences ou de provoquer des temps d'arrêt ?

3. Il existe des changements incompatibles entre les versions majeures de Solr

Solr a considérablement évolué. Le passage des anciennes versions aux versions plus récentes de Solr nécessite parfois de repenser les paramètres de sécurité, la compatibilité des plugins et les structures de configuration.

4. Solr prend en charge les applications héritées dont le développement n'est plus assuré

De nombreuses entreprises continuent d'utiliser Solr pour prendre en charge d'anciennes gammes de produits ou des outils internes. Ces systèmes sont stables, génèrent des revenus et justifient rarement une refonte complète de la plateforme de recherche.

5. La prise en charge de Solr sous Windows a pris les équipes au dépourvu

Solr suit un cycle de publication et de retrait que de nombreuses organisations ne suivent pas de près. Un jour, vous utilisez la version 7.x ou 8.x, et le lendemain, vous apprenez que les mises à jour critiques ne sont plus disponibles.

C'est précisément à ce moment-là que surgissent les inquiétudes concernant une vulnérabilité d'Apache Solr – car utiliser une version de Solr qui n'est plus prise en charge ne se résume pas à une absence de fonctionnalités. Il s'agit surtout d'une absence de correctifs de sécurité.

Mais voici la bonne nouvelle : avec la bonne approche, vous pouvez garantir la stabilité, la performance et la sécurité des anciennes versions de Solr.

Et tout commence par la surveillance.

Pourquoi la surveillance revêt une importance particulière pour les déploiements Solr existants par rapport aux déploiements modernes

La surveillance des nouveaux clusters Solr est simple : tout est documenté, pris en charge et compatible avec le cloud. Mais qu'en est-il de la surveillance des anciennes versions ? C'est une tout autre histoire.

Voici pourquoi une surveillance approfondie d'Apache Solr est indispensable :

1. Les anciennes versions de Solr comportent davantage d’« inconnues cachées »

Les petites fuites de mémoire, les fusions lentes, les configurations obsolètes et les caprices de la JVM ont tendance à se manifester progressivement. On ne s'en rend compte que lorsque les performances de recherche se dégradent soudainement ou que l'indexation ralentit.

La surveillance permet de détecter les premiers signes bien avant que les utilisateurs n'en ressentent les effets.

2. Vous ne disposez pas toujours de techniciens de remplacement

Lorsque l'architecte à l'origine de Solr a quitté l'entreprise il y a cinq ans, il a emporté avec lui une grande partie de son savoir-faire. La surveillance permet de combler ces lacunes.

3. Les journaux ne suffisent pas à eux seuls

Les anciennes versions de Solr génèrent parfois des journaux de bord incohérents ou imprécis. Les métriques vous apportent la clarté que les journaux de bord ne peuvent pas offrir.

4. Les environnements Solr existants sont souvent surdimensionnés

De plus, la surveillance vous aide à adapter vos ressources de manière optimale et en toute sécurité, afin de ne pas payer pour de la mémoire vive ou de la puissance de calcul inutilement.

5. La sécurité en dépend

Les failles de sécurité de Solr – en particulier les plus anciennes – sont souvent exploitées pour :

• erreurs de configuration
• points d'extrémité exposés
• cœurs non protégés
• communications non sécurisées au sein d'un cluster
• bibliothèques obsolètes

On ne peut pas réparer ce qu'on ne voit pas.

Les éléments à surveiller dans les clusters Solr plus anciens (que la plupart des équipes oublient)

La plupart des équipes surveillent les indicateurs de base : utilisation du processeur, utilisation de la mémoire, temps d'exécution des requêtes. Mais les clusters plus anciens nécessitent une visibilité plus approfondie.

Voici les indicateurs qui font toute la différence :

1. Pools de mémoire de la JVM

Les anciennes versions de Solr s'appuient fortement sur la JVM, et le comportement du ramasse-miettes peut vous en dire plus sur l'état de santé de votre système que presque tout autre élément.

À surveiller :

• longues pauses du GC
• taux d'occupation élevé des logements de l'ancienne génération
• pics soudains d'Eden
• échecs en matière de promotion

Ces signes indiquent souvent une instabilité précoce.

2. Répartition des temps de latence des requêtes (au-delà des simples moyennes)

La latence moyenne masque les problèmes. Les valeurs P95 et P99 révèlent ce que vivent réellement les utilisateurs aux limites du réseau.

3. Comportement de la politique de fusion

Les fusions d'index peuvent ralentir l'ensemble du cluster si elles se désynchronisent au fil du temps.

Recherchez :

• accumulation dans la file d'attente de fusion
• tâches de fusion de longue durée
• nombre excessif de segments

4. Retard de réplication

Le fait qu'un nœud prenne du retard constitue un signe avant-coureur de problèmes de performance plus graves.

5. Saturation des E/S disque

Les anciens déploiements Solr reposent souvent sur des disques obsolètes – et il est impossible de résoudre les problèmes d'E/S au niveau de Solr.

6. Épuisement du pool de threads

Lorsque les pools de threads internes de Solr atteignent leur limite maximale, la recherche risque de devenir instable d'une seconde à l'autre.

7. Cycles de validation lents ou ayant échoué

Cela met souvent en évidence :

• problèmes de schéma
• mises à jour d'index incorrectes
• lenteur des écritures sur le disque
• nœuds sous-dimensionnés

8. Erreurs cachées dans /admin/metrics ou dans les journaux

Les anciennes versions de Solr génèrent parfois des avertissements qui semblent anodins, mais qui indiquent un risque de corruption de l'index.

La surveillance n'est pas simplement un « plus ». C'est votre principal mécanisme de défense.

Le problème de sécurité : que se passe-t-il lorsque le support de Solr prend fin ?

C'est en matière de sécurité que les choses deviennent sérieuses. Des accès non autorisés à Solr ont déjà entraîné de graves incidents par le passé, notamment la divulgation de données, l'exécution de code à distance et le chiffrement d'index par des ransomwares.

Lorsque le support d'Apache Solr prendra fin pour la version que vous utilisez, voici ce qui changera :

1. Fini les correctifs

Si une nouvelle faille de sécurité est découverte dans la version que vous utilisez, vous devrez vous débrouiller tout seul.

2. Pas de correctifs rétroportés

Les correctifs critiques ne s'appliquent qu'aux versions actuellement prises en charge.

3. Les pirates savent quelles versions sont vulnérables

Les kits d'exploitation identifient automatiquement les versions qui ne sont pas mises à jour.

4. Les anciens plugins deviennent des vecteurs d'attaque

Les plugins qui dépendent de bibliothèques obsolètes ne reçoivent plus de mises à jour non plus.

5. Le durcissement se complique

Tu passes plus de temps à défendre le système qu’à l’utiliser.

C'est pourquoi la question des alternatives à Apache Solr fait désormais l'objet de discussions : Elasticsearch, OpenSearch, Meilisearch et les services de recherche natifs du cloud semblent être des options intéressantes à mesure que Solr arrive en fin de vie.

Mais remplacer Solr est rarement simple, surtout si votre écosystème est étroitement intégré à sa logique d'indexation.

Que faire si la mise à niveau n'est pas possible pour le moment ?

Vous gagnez du temps en réduisant votre surface d'attaque et en modernisant votre système de surveillance.

Comment assurer la sécurité des anciennes versions de Solr sans tout réécrire

Voici l'approche pratique et concrète que les équipes d'ingénieurs adoptent pour protéger les clusters Solr existants sans pour autant se débarrasser de l'infrastructure en place.

1. Verrouiller tous les points de terminaison Solr

Les anciennes installations de Solr présentent un risque lorsqu'elles sont exposées à l'Internet public, même par inadvertance.

Ne permettez jamais l'accès sans authentification à :

• /solr/admin
• /solr/config
• /solr/update
• /solr/select (lorsqu'il existe des paramètres modifiables)

Utilisez un proxy inverse, un pare-feu ou des règles de réseau privé.

2. Imposer l'utilisation du protocole TLS partout

Les anciens clusters Solr fonctionnent souvent en texte clair. C'est une aubaine pour les pirates qui interceptent le trafic.

3. Remplacer tous les anciens plugins d'authentification

Les plugins obsolètes constituent l'une des failles de sécurité les plus courantes de Solr.

4. Renouveler régulièrement les identifiants et les clés

Surtout si plusieurs équipes ont travaillé sur le cluster au fil des ans.

5. Mettre à jour les dépendances liées à Solr

Même si Solr ne peut pas être mis à jour, vous pouvez tout de même installer des correctifs :

• paquets système
• JVM
• images de base pour conteneurs
• Dépendances de Zookeeper
• Bibliothèques au niveau du système d'exploitation

6. Ajouter la détection des anomalies en temps réel

Utilisez des outils qui détectent :

• connexions sortantes soudaines
• appels inattendus à l'API Solr
• modèles de manipulation d'index
• motifs de pics suspects

Les outils de surveillance modernes (Prometheus, Grafana, Datadog, OpenTelemetry, etc.) prennent tous en charge cette fonctionnalité.

7. Ajouter un Canary Core

Cette petite astuce est d'une grande aide.

Un « canary core » fait office de « système d'alerte précoce » contrôlé, dont le contenu est connu. Si les résultats de recherche ou la latence varient de manière inattendue, vous savez que le cluster présente un dysfonctionnement avant même que cela n'affecte l'environnement de production.

8. Mettre en place un parcours de mise à niveau sans précipitation

Vous n'avez pas besoin de passer à Solr 9 dès demain, mais élaborez un plan de migration qui décompose le processus en petites étapes à faible risque.

Quand vous ne pouvez pas encore passer à la version supérieure (et pourquoi ce n’est pas grave)

Dans le secteur des technologies, on subit une forte pression pour « se contenter de mettre à jour », mais les systèmes de production réels ne le permettent pas toujours.

Parfois :

• le schéma est trop personnalisé
• l'entreprise ne peut pas se permettre de subir des temps d'arrêt
• la migration implique trop d'éléments en mouvement
• la logique de recherche est étroitement intégrée à l'application
• l'équipe n'a pas les moyens de s'en occuper ce trimestre

C'est normal.

L'important, c'est que vous protégiez votre système actuel de manière responsable.

Et si vous avez besoin d'une protection à long terme pour une version plus ancienne qui n'est plus prise en charge, des solutions telles que celles proposées par TuxCare Endless Lifecycle Support pour Apache Solr existent spécifiquement pour assurer la sécurité de ces systèmes critiques pendant que vous planifiez une migration plus sûre.

La surveillance d'Apache Solr n'est pas facultative : c'est votre bouée de sauvetage

Ce n'est pas l'ancienne version de Solr qui pose problème. C'est le manque d'entretien.

Les anciennes versions d'Apache Solr peuvent fonctionner en toute sécurité – même à grande échelle – si vous les traitez comme les systèmes critiques qu'elles sont. Cela implique une surveillance rigoureuse, un renforcement délibéré de la sécurité et une stratégie de migration que vous maîtrisez, et non une stratégie dictée par des dates de fin de vie.

Car la stabilité ne tient pas au fait d'utiliser la toute dernière version.

Cela tient à la visibilité, au contrôle et à une protection constante.

Si vous vous y prenez bien, même l'ancienne version de Solr ne paraîtra plus dépassée.

Résumé

Nom de l'article

Sécurité Apache Solr pour les systèmes hérités | Maintenir les correctifs après la fin de vie

Description

Vous utilisez une ancienne version d'Apache Solr ? Découvrez comment surveiller les performances, détecter les risques et garantir la sécurité après la fin de vie du produit, sans précipiter les mises à niveau.

Auteur

Tim Walker

Nom de l'éditeur

de TuxCare

Logo de l'éditeur