Kibana: Kibana 4.2.0 ne peut plus être mandaté sous un répertoire

@ dfr0
Le terrain de travail de
et je pense que ça devrait marcher pour toi aussi
eh bien, j'ai fait une petite modification:

ProxyRequests désactivé

ProxyPass / app / kibana http: // localhost : 5601 / app / kibana
ProxyPassReverse / app / kibana http: // localhost : 5601 / app / kibana

ProxyPass / bundles http: // localhost : 5601 / bundles
ProxyPassReverse / bundles http: // localhost : 5601 / bundles

ProxyPass / elasticsearch http: // localhost : 9200
ProxyPassReverse / elasticsearch http: // localhost : 9200

Bien sûr, je ne sais pas qu'elasticsearch a besoin de votre propre proxy ou emplacement, j'ai découvert cela il y a quelques heures avec les outils de développement Chrome, f *

Mais les options de statut ne fonctionnent pas, avez-vous le même problème avec ça ???

Merci pour tout.

@ dfr0 peut-être que vous devriez démarrer un nouveau fil de discussion pour le problème des "options d'état", je n'ai aucune idée de quoi il s'agit

merci pour la réponse rapide.

Ici, vous montrez des captures d'écran de ma machine virtuelle de test, sur cette machine, kibana fonctionne correctement "presque :)" mais sur le cloud, l'application d'état ne fonctionne pas.

Je vais créer un nouveau numéro pour ça, merci beaucoup

@ dfr0 Vous aurez besoin de plus d'entrées dans votre configuration de proxy pour gérer également la page d'état:

ProxyPass /status http://127.0.0.1:5601/status
ProxyPassReverse /status http://127.0.0.1:5601/status
ProxyPass /api/status http://127.0.0.1:5601/api/status
ProxyPassReverse /api/status http://127.0.0.1:5601/api/status

Si vous utilisez l'option "Inspecter l'élément" de Chrome et sélectionnez l'onglet "Console", vous pouvez voir les URL auxquelles Kibana tente de se connecter, et si l'un des préfixes d'URL ne figure pas dans votre paramètre de proxy inverse Apache, ajoutez simplement et faire rebondir Apache.

: D Thx tellement, je n'ai pas vu l'onglet de la console, je ne vois que sur l'onglet réseau.

Travaillez correctement thx.

mon équilibreur nginx a cessé de fonctionner avec kibana.
tout le reste fonctionne comme prévu.
c'est la configuration qui fonctionnait avant la mise à jour:

/etc/nginx/conf.d/elastic-80.server.conf

upstream web {

    server elk-node-01;
    server elk-node-02;
    server elk-node-03;

    keepalive 5;
}

server {

    listen 80;

    location / {

        proxy_pass http://web;
        proxy_http_version 1.1;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
    }

    access_log /var/log/nginx/access-80.log;
    error_log  /var/log/nginx/error-80.log;
}

maintenant ce n'est plus le cas.

Malheureusement, je peux confirmer que server.basePath: "/ kibana" dans kibana.yml ne fonctionne pas comme prévu. Visiter http://myserver.com/kibana/ entraîne un HTTP 200 avec uniquement le texte d'erreur JSON sur 404 Not Found. C'est avec Kibana 4.3.1 (de l'archive tar officielle) sur CentOS 7.2. Si je ne configure pas server.basePath, Kibana fonctionne comme prévu. Cependant, il reprend simplement le contexte racine de mon HAProxy. Cela reste une étape décisive pour notre déploiement multi-applications proxy.

@guydavis il semble que votre proxy ne supprime pas /kibana de la requête avant de l'envoyer à Kibana. Il doit faire cela pour que la fonctionnalité fonctionne correctement.

@guydavis , je l'ai fait fonctionner à nouveau. a expliqué ma configuration ici: https://discuss.elastic.co/t/4-3-0-how-to-configure-your-nginx-balancer-and-apache-reverse-proxy/37351/2?u=yodog

Je suis confronté au même problème. J'ai une configuration nginx pour plusieurs applications. Je ne parviens pas à faire fonctionner kibana sous un sous-dossier / kibana

Quelle est la configuration de nginx lorsque nous utilisons server.Path?

J'ai pu faire fonctionner les plugins kibana 4.3.1 et ES via Nginx, en utilisant le détail @damm publié le 30/10/2015, et une directive d'emplacement distincte pour gérer les plugins. J'ai dû ajouter "elasticsearch" comme chemin dans la directive d'emplacement pour Kibana, car mes journaux révélaient des requêtes dirigées vers ce chemin, et sans cela, je n'obtiendrais aucune information dans mes écrans Kibana). La deuxième directive gère les plugins ES que j'utilise (en particulier "hq"). Le plugin "kopf" ne se connecte que si j'ai le chemin "/" dans la directive. Voici les directives de localisation nginx:

location ~ (/ app / kibana | / bundles / | / kibana4 | / status | / plugins | / elasticsearch) {
proxy_pass http: // localhost : 5601;
proxy_http_version 1.1;
proxy_set_header Mise à niveau $ http_upgrade;
proxy_set_header Connexion "mise à niveau";
proxy_set_header Hôte $ hôte;
réécrire /kibana4/(.*)$ / $ 1 break;
access_log /opt/nginx-1.8.0/logs/kibana-access.log;
error_log /opt/nginx-1.8.0/logs/kibana-error.log;
}

emplacement ~ (/ | / _plugin) {
proxy_pass http: // localhost : 9217;
access_log /opt/nginx-1.8.0/logs/esplugin-access.log;
error_log /opt/nginx-1.8.0/logs/esplugin-error.log;
}

J'écoute sur le port 443 et j'accède aux plugins Kibana et ES comme:
Kibana: https: //./ app / kibana
Plugins ES: https: //./_brancher/

J'espère que cela aide quelqu'un, car c'est un ours qui essaie de faire fonctionner à nouveau tout cela à chaque fois qu'Elastic décide de changer de direction.

@ ksou1 vous n'avez pas besoin d'emplacements séparés si vous suivez les instructions affichées ici: https://discuss.elastic.co/t/4-3-0-how-to-configure-your-nginx-balancer-and-apache-reverse -proxy / 37351/2? u = yodog

Définir _kibana.yml's_ server.basePath et m'assurer que mon proxy Orchard CMS transmet les en-têtes HTTP personnalisés a fait l'affaire pour moi. Je recevais un 400 (mauvaise requête) sur les messages _elasticsearch / _mget_ jusqu'à ce que je passe l'en-tête kbn_version .

Je suis sur Kibana 4.5.3, lorsque vous définissez server.basePath sur /kibana vous pouvez utiliser une version modifiée de la configuration de l'emplacement NGINX de

location /kibana/ {
        proxy_pass http://localhost:5601;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        rewrite /kibana/(.*)$ /$1 break;
    }

Comme déjà souligné, je suppose également que le paramètre server.basePath ne fonctionne pas comme prévu, la réécriture ne devrait pas être nécessaire. Cependant, la configuration modifiée fonctionne parfaitement bien pour moi et ne casse pas mes autres emplacements.

J'ai tout essayé à partir de ce fil - mais seule la solution de @ ksou1 a fonctionné pour moi.
J'ai également ajouté la redirection /kibana vers /app/kibana comme raccourci.

location ~ (/app/kibana|/bundles/|/kibana4|/status|/plugins|/elasticsearch) {
    proxy_pass http://localhost:5601;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    rewrite /kibana4/(.*)$ /$1 break;
}

J'ajoute / elasticsearch, c'est ok

@linzhaolover pouvez-vous expliquer la raison du bit 'Upgrade $ http_upgrade'?

La suggestion de @damm a presque fonctionné pour moi. J'avais juste besoin d'ajouter / elasticsearch à l'expression régulière aussi. J'utilise également http2, donc cela fonctionne mieux pour moi:

    location ~ (/app/kibana|/bundles/|/kibana4|/status|/plugins|/elasticsearch) {
        proxy_pass              http://10.23.251.150:5601;
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_set_header        X-Forwarded-Host $http_host;
    }

Mon emplacement mis à jour pour kibana 5.2.2 est le suivant:

location ~ (/app/kibana|/bundles|/es_admin|/plugins|/api|/ui|/elasticsearch) {
    proxy_pass              http://10.23.251.150:5601;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_set_header        X-Forwarded-Host $http_host;    
}

Je n'ai trouvé aucun problème jusqu'à présent, cela semble donc suffisant pour la version actuelle. Ou est-ce que je manque quelque chose?

la plupart des solutions fournies ici ne prennent pas en compte des cas tels que des services supplémentaires sur un même serveur derrière un proxy inverse et ne fonctionnent donc pas correctement

par exemple, une solution avec /status à l'emplacement causera des problèmes à un Nexus, car son URL contient des liens comme celui-ci:

https://fqdn/nexus/service/local/outreach/status?_dc=0

comme vous pouvez le voir, l'expression régulière correspondra à ce cas

un autre problème avec /elasticsearch et aussi avec Nexus, si vous téléversez l'artefact elasticsearch dans Nexus, vous ne pourrez pas le télécharger, car l'URL correspondra à l'expression régulière

@ t3chn0m4g3 Vous n'avez pas besoin de la règle de réécriture si vous définissez correctement proxy_pass avec une barre oblique finale:

location /kibana/ {
    proxy_pass http://localhost:5601/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

La différence est expliquée ici: https://www.nginx.com/resources/admin-guide/reverse-proxy/