home » search tags
Die Suche tag = elasticsearch ergab 16 Treffer:

Januar
27
Wie ich hier bereits geschrieben habe, wurde der Veröffentlichung von shield für elasticsearch sehnlichst von mir entgegengefiebert... Aber was muss ich lesen:
...Shield enriches our Gold and Platinum subscription...

ôO

Es gibt zwar die Möglichkeit eine 30tägige trial zu erhalten, aber ich konnte auf der ganzen Webseite nichts zu den Preisen der einzelnen Supportverträge finden (transparenz sieht anders aus).

** Update **

Mail an elasticsearch bzgl. Supportpreise ist raus und ich bin gespannt.

November
22
Wer elasticsearch in einer Produktivumgebung einsetzt der hat sicherlich mehr als einmal die fehlenden Sicherheitsmechanismen vermisst.

Wenn man elasticsearch.org glauben darf, wurde das flehen der Kunden/Community erhöht, denn mit shield soll sich einiges in dieser Richtung ändern (und hoffentlich auch verbessern).

Folgende Erweiterungen sollen u.a. in shield enthalten sein:
  • RBAC (roll based access controls)
  • Authentication (Login mit Benutzer + Passwort)
  • Encrypted Communications (verschlüsselte Kommunikation)

Leider gibt es aktuell keine Testversion, aber eins steht fest... sobald diese verfügbar ist wird ein ausführlicher Test auf uselessmouse.de erscheinen.
November
22
Da ist doch glatt am 11.11.2014 eine neue beta von Kibana4 erschienen und ich hab es nicht mitbekommen.

Wenn ich mir den entsprechenden Blogpost und die Screenshots ansehe, dann muss ich sagen nice. Mal sehen welchen Eindruck es hinterlässt wenn ich endlich Zeit finde es auf einem Testsystem mal live zu sehen. Alleine der map support macht diese Version so interessant.
November
4
Wie hier bereits beschrieben kann man das off. repo von elasticsearch mittels Puppet aktivieren.

Möchte man nun elasticsearch installieren, kann man folgenden Code in seinem Manifest nutzen
package { 'elasticsearch pkg' :
ensure => 'latest',
name => 'elasticsearch',
}



Um die benötigte Abhänigkeit zwischen repo und Paket zu definieren, muss die entsprechende Klasse um
before      => Package['elasticsearch pkg'],

erweitert werden.

Alles zusammen in einem Manifest würde dann wie folgt aussehen
class elasticsearch::install {

include apt

apt::source { 'elasticsearch.list' :
before => Package['elasticsearch pkg'],
location => 'http://packages.elasticsearch.org/elasticsearch/1.3/debian',
repos => 'stable main',
release => '',
key => 'D88E42B4',
key_source => 'http://packages.elasticsearch.org/GPG-KEY-elasticsearch',
include_src => false,
}

package { 'elasticsearch pkg' :
ensure => 'latest',
name => 'elasticsearch',
}

}

November
3
Da elasticsearch passende repos für DEB bzw. RPM zur Verfügung stellt, stellte sich die Frage wie kann ich diese per Puppet einbinden?.

Hierzu bietet Puppet-Labs ein passendes Modul Namens apt an.

Um das repo von elasticsearch auf einem System zu aktivieren, kann folgender Code im entsprechenden Manifest genutzt werden
include apt

apt::source { 'elasticsearch' :
location => 'http://packages.elasticsearch.org/elasticsearch/1.3/debian',
repos => 'stable main',
release => '',
key => 'D88E42B4',
key_source => 'http://packages.elasticsearch.org/GPG-KEY-elasticsearch',
include_src => false,
}

September
19
Wie bereits geschrieben hatte ich das Glück ein Elasticsearch Training zu besuchen, alles in allem war es ein wirklich gelungenes Training.

Nachträglich gab's auch die gezeigten Folien als PDF (leider mit meiner Mailadresse als Wasserzeichen), was mich aber wirklich wundern und massiv stört ist die Tatsache das dieses PDF mit einem User- und Ownerpasswort geschützt ist, d.h. ich muss bei jedem öffnen des Dokuments das entsprechende Passwort (nach dem Muster "adazdanf4n371hKJ47DHkjashkas") angeben! ôO

OK, ich kann verstehen das Elasticsearch nicht möchte das die Dokumente unbefugt weitergegeben werden, von daher kann ich das Wasserzeichen verstehen.

Aber welchen Sinn macht das Passwort?

Jeder halbwegs denkende wird das PDF öffnen, "Drucken" auswählen und in ein neues PDF (ohne Passwort) abspeichern.
September
16
Aktuell ist eines meiner Lieblingsthemen elasticsearch, daher geht's heute nach Berlin um an der Schulung core elasticsearch teilzunehmen.

Ich bin wirklich gespannt was/ob es für mich etwas neues zum Thema zu erfahren gibt.
Mai
2
Mittels facets lassen sich bestimmte Felder anhand ihres vorkommens suchen und zusammenfassen.

Wie man losgstash beibringen kann die GeoIP-Daten zu nutzen, habe ich hier bereits geschrieben.

Wer z.B. die logfiles seines Mailservers in Elasticsearch sammelt, kann z.B. eine Statistik der Top SPAM Länder erstellen. Da ich Einträge von Postfix mit _type = postfix und SPAM mit tag = msg_spam versehe, sieht das passende query/facets wie folgt aus:

{
"fields" : ["geoip.country_code2"],
"query" :{
"bool" : {
"must" : {
"term" : {
"type" : "postfix"
}
},
"must" : {
"term" : {
"tags" : "msg_spam"
}
}
}
},
"facets" : {
"laender" : {
"terms" : {
"field" : "country_code2",
"size" : 10
}
}
}
}



Die dazu passende Ausgabe wäre dann:

{u'count': 69, u'term': u'ru'}
{u'count': 48, u'term': u'gb'}
{u'count': 37, u'term': u'us'}
{u'count': 34, u'term': u'ar'}
{u'count': 30, u'term': u'es'}
{u'count': 28, u'term': u'vn'}
{u'count': 24, u'term': u've'}
{u'count': 24, u'term': u'sa'}
{u'count': 22, u'term': u'tw'}
{u'count': 18, u'term': u'ua'}

April
29
Logstash hat die nette Eigenschaft automatisch das Feld @timestamp beim schreiben in elasticsearch zu erstellen. Dieses bietet sich immer wunderbar zum filtern an.

Wenn man nun aber eigene Daten in elasticsearch ablegen möchte ist das Feld @timestamp bzw. _timestamp nicht unbedingt vorhanden... was tun?

Gehen wir von folgendem Beispiel aus

{
"userID" : "0815" ,
"itemCount" : "1" ,
"mydate" : "2014-04-28 11:30:21" ,
"data" : {"OS" : "Windows7", "version" : "2013.12.0.3"}
}



zwar finden wir hier eine Feld mydate welches aber nur als string übergeben wird, somit ist es nicht möglich Abfragen nach dem Muster zeige Daten der letzten x Tage an zu realisieren.

Doch elasticsearch bietet eine Möglichkeit des mappings an.

Möchte man automatisch einen passenden timestamp erstellen, sobald die Daten in elasticsearch abgelegt werden, hilft folgendes mapping

"_timestamp" : {
"enabled" : true,
"store" : "yes"
}



Möchte man hingegen _timestamp anhand eines bestehenden Feldes generieren (in diesem Falle anhand von mydate) kann das folgende mapping genutzt werden

"_timestamp" : {
"enabled" : true,
"store" : "yes",
"path" : "mydate",
"format" : "yyyy-MM-dd HH:mm:ss"
}

April
25
Mittels fail2ban lassen sich (mehr oder weniger) wirksam und automatisiert, unerwünschte Zugriff auf einen Server verhinden und protokollieren.

Um die Daten (z.B. wer hat wann, wie und auf welche Art versucht sich unlauter am System anzumelden) zu visualisieren gibt es verschiedene Ansätze.
Aktuell nutze ich auf div. Systemen eine Mischung aus Logstash, Elasticsearch und Kibana.

Ich gehe davon aus, das bereits eine Umgebung der genannten Komponenten läuft und gehe daher nicht auf die Installation ein.

Die von mir genutzte Konfiguration von fail2ban sieht wie folgt aus

loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock



Wichtig für die weitere Konfiguration ist der Pfad zum Logfile (logtarget), in diesem Beispiel /var/log/fail2ban.log

Die Einträge im Logfile haben folgendes Muster (wobei www.xxx.yyy.zzz die IP darstellt):

2014-04-24 03:43:11,315 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 05:17:38,490 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 10:51:26,914 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 16:20:17,831 fail2ban.actions: WARNING [postfix] Ban www.xxx.yyy.zzz
2014-04-24 18:40:26,777 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 23:23:48,630 fail2ban.actions: WARNING [sasl] Unban www.xxx.yyy.zzz
2014-04-25 03:43:11,729 fail2ban.actions: WARNING [ssh] Unban www.xxx.yyy.zzz



Um das Logfile korrekt von Logstash verarbeiten zu lassen, benötigen wir passende Filter:

FAIL2BAN %{GREEDYDATA:timer} fail2ban.actions: %{GREEDYDATA:severity} \
[%{GREEDYDATA:service}\] %{FAIL2BAN_ACTION:action} %{IPV4:remoteaddr}



Nun kann man das Logfile von fail2ban in Logstash einbinden:

input {
file {
path => "/var/log/fail2ban.log"
type => "fail2ban"
tags => "fail2ban,system,security"
}
}

filter {
if [type] == "fail2ban" {
grok {
patterns_dir => ["/opt/logstash/patterns"]
match => ["message", "%{FAIL2BAN}"]
add_tag => [ "fail2ban_action" ]
}
}
if [remoteaddr] {
geoip {
source => "remoteaddr"
target => "geoip"
database => "/opt/logstash/GeoLiteCity.dat"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}

}



Nach einem restart/reload von Logstash muss man nur warten (was meist nicht sonderlich lange dauert) bis die ersten Zugriffe von fail2ban geloggt wurden.

Anschließend kann man innerhalb von Kibana (über den Tag fail2ban) die anfallenden Daten visualisieren:

Im folgenden Beispiel sind die Aktionen wie folgt eingefärbt:

Ban = grün
Unban = gelb

April
2
Wer elasticsearch/logstash nutzt, der nutzt meist auch Kibana zur Visualisierung.

Die passende conf für Nginx sieht dabei wie folgt aus

location /kibana {
auth_basic "Kibana";
auth_basic_user_file /srv/www/htpasswd.users;
alias /srv/www/html/kibana;
}

# Password protected end points
location ~ ^/kibana-int/dashboard/.*$ {
proxy_pass http://elasticsearch;
proxy_read_timeout 90;
limit_except GET {
proxy_pass http://elasticsearch;
auth_basic "Kibana";
auth_basic_user_file /srv/www/htpasswd.users;
}
}

location ~ ^/kibana-int/temp.*$ {
proxy_pass http://elasticsearch;
proxy_read_timeout 90;
limit_except GET {
proxy_pass http://127.0.0.1:9200;
auth_basic "Kibana";
auth_basic_user_file /srv/www/htpasswd.users;
}
}



Den passenden upstream kann man wie folgt definieren

upstream elasticsearch {
server 127.0.0.1:9200;
keepalive 32;
}

April
2
Da elasticsearch keine (einfache) Möglichkeit bietet den Zugriff zu beschränken, bietet sich Nginx als vorgeschalteter reverse proxy an.

Damit ES nicht auf alle Adressen lauscht, muss der Parameter network.host in config/elasticsearch.yml wie folgt angepasst werden

network.host: 127.0.0.1



Das Setup von Nginx ist relativ einfach.

Ich gehe davon aus das Nginx und ES auf einem Host laufen und die Zugriffe ohne Authentifizierung funktionieren sollen

upstream elasticsearch {
server 127.0.0.1:9200;
keepalive 32;
}

server {
listen 80;
server_name localhost;

access_log /var/log/nginx/nginx_elasticsearch_access.log main;
error_log /var/log/nginx/nginx_elasticsearch_error.log;

root /srv/www/default;
index index.html index.htm;

location / {
proxy_pass http://elasticsearch;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass_header Access-Control-Allow-Origin;
proxy_pass_header Access-Control-Allow-Methods;
proxy_hide_header Access-Control-Allow-Headers;
add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type';
add_header Access-Control-Allow-Credentials true;
}
}

März
27
Was macht man nun mit seiner frischen Installation von elasticsearch?

Als kleines Beispiel habe ich einen Indexer erstellt, der ein definiertes Verzeichnis nach Dateien durchsucht und deren Inhalt in ES ablegt.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import magic
import os
import elasticsearch
from datetime import datetime

indexName = "local-fs"

baseDir = "/home/user"

wantedMime = ['text/x-python', 'text/x-perl', 'text/x-shellscript', 'text/plain']

#-- initialize elasticsearch connection
es = elasticsearch.Elasticsearch("localhost:9200")

#-- read given directory
for dirName, dirNameList, fileNameList in os.walk(baseDir):
for fileName in fileNameList:
filePath = os.path.join(dirName, fileName)
#-- guess file/mime type
mimeType = magic.from_file(filePath, mime=True)
#-- if mimetype is wanted
if mimeType in wantedMime:
#-- read content
with open(filePath, 'r') as infile:
filedata = infile.read()
#-- write everything to elasticsearch
es.index(index=indexName,
doc_type="fs",
body = {
"timestamp": datetime.now(),
"filename": fileName,
"filepath": dirName,
"mimetype": mimeType,
"content": filedata,
})



Das benötigte Pythonmodul magic lässt sich wie immer einfach per pip installieren

sudo pip install python-magic



Wie kommt man aber wieder an die gespeicherten Daten ran? Ein einfacher/schneller weg ist curl

Möchte man z.B. alle Dokumente mit dem mimetype python sehen, genügt der folgende Aufruf:

curl -XGET 'http://localhost:9200/local-fs/_search?pretty' -d \
'{"query":{"bool":{"must":[{"query_string":{"default_field":"fs.mimetype","query":"python"}}],\
"must_not":[],"should":[]}},"from":0,"size":50,"sort":[],"facets":{}}'

März
26
Ich komme kaum mit dem Updates von elasticsearch hinterher, denn kaum habe ich eine Anleitung für 1.0.1 geschrieben, ist Version 1.1.0 raus. Den passenden Download gibt's hier

Da mich die laaange Liste der breaking changes, new features, enhancements und bugfixes überzeugt hat, sind nun alle meine ES-Systeme aktualisiert.

Bei dieser Gelegenheit habe ich auch gleich Logstash von 0.9.0 auf die passende Version 1.4.0 aktualisiert.
März
21
Da ich in den letzten Wochen/Monaten mich verstärkt dem Thema Logstash/Elasticsearch gewidmet habe, hier nun eine kleine Anleitung zur Installation eines Basis-/Testsystems.

Die Konfiguration von ES für den Livebetrieb sind u.U. umfangreich und abhängig von der vorhandenen Hardware und dem geplanten Einsatz.

Die aktuellste Version von ES kann man auf deren Webseite finden. Bei der hier genutzten Version handelt es sich um Version 1.0.1

Der Download klappt am einfachsten direkt per wget
wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.1.tar.gz



Anschließend kann man das Paket entpacken

tar xfz elasticsearch-1.0.1.tar.gz



Da ich meist mit verschiedenen Versionen arbeite, möchte ich über cd /opt/elasticsearch/ immer im passenden Verzeichnis laden, daher lege ich einen symbolischen Link an

ln -s elasticsearch-1.0.1/ /opt/elasticsearch



Die konfiguration von ES geschieht über die Datei elasticsearch/config/elasticsearch.yml und ist aufgrund der ausführlichen Dokumentation quasi selbsterklärend. Für das Testsystem ist das anpassen der folgende Parameter ausreichend

cluster.name: Jedi
node.name: "Yoda"



Um keinerlei externe Zugriffe zu ermöglichen, kann man noch den folgenden Parameter anpassen

network.host: 127.0.0.1



Nun kann man ES starten (ich starte es in einem screen)

screen -S elasticsearch /opt/elasticsearch/bin/elasticsearch



Die folgende Meldung zeigt an, das ES erfolgreich gestartet wurde

...
[2014-03-21 14:17:06,378][INFO ][node] [Yoda] started



Kontrollieren kann man es (nach STRG a + d um den screen abzuhängen) mittels netstat -tulpen | grep 9200
tcp6    0    0 127.0.0.1:9200    :::*    LISTEN    1000    3948810    5483/java



oder im Browser über die URL http://localhost:9200

{
"status" : 200,
"name" : "Yoda",
"version" : {
"number" : "1.0.1",
"build_hash" : "5c03844e1978e5cc924dab2a423dc63ce881c42b",
"build_timestamp" : "2014-02-25T15:52:53Z",
"build_snapshot" : false,
"lucene_version" : "4.6"
},
"tagline" : "You Know, for Search"
}

März
18
Für eine meiner elasticsearch-Installationen war ich auf der Suche nach einem passenden frontend/dashboard um alle Parameter zu überwachen.

Über zwei wirklich geniale Plugins bin ich dabei gestolpert:



Zu zwei werde ich demnächst genauere Tests posten.