un listener qui permet d'envoyer un seul evenement logstash pour plusieurs lignes de logs.
Si on a la main sur le code source, c'est quand meme plus simple de logger en json : 1 ligne = 1 event
Dans ce cas on peut utiliser le plugin imfile de rsyslog pour surveiller le fichier et envoyer les events :)
ah genial pour balancer du stream sur la tv!
Pour envoyer direct dans ES depuis rsyslog
(se passer de logstash devient donc possible dans certains cas)
Sympa la fonction dans les commentaires, mais pour un gros historique, penser à rajouter un "-l 3" au svn log pour avoir seulement l'historique des 3 derniers changements.
La version modifée avec le "-l 3" :
#
function history_of_file() {
url=$1 # current url of file
svn log -l 3 -q $url | grep -E -e "^r[[:digit:]]+" -o | cut -c2- | sort -n | {
echo
read r
svn log -r$r $url@HEAD
svn cat -r$r $url@HEAD
echo
while read r
do
echo
svn log -r$r $url@HEAD
svn diff -c$r $url@HEAD
echo
done
}
}
history_of_file $1
Dans la vue Discover de Kibana4, si vous ne voyez pas tous les champs d'une entrée....
Tentez cette manip' : Settings > Indices > Select your indice (logstash-*) > then refresh..
Cette liste a parfois du mal à se rafraichir si il y a trop de documents/de champs (PS : plusieurs heureuse de debug sans résultat, la solution m'a été donnée sur irc : freenode#kibana) thx rashidkpc
Le système de plugin d'elasticsearch est vraiment bien foutu.
Quelques plugins sympa pour avoir un aperçu de la santé de son cluster :
https://github.com/karmi/elasticsearch-paramedic
https://github.com/mobz/elasticsearch-head
https://github.com/lukas-vlcek/bigdesk
Pour les installer, c'est à chaque fois pareil, en une ligne :
/usr/share/elasticsearch/bin/plugin -install lukas-vlcek/bigdesk
/usr/share/elasticsearch/bin/plugin -install karmi/elasticsearch-paramedic
/usr/share/elasticsearch/bin/plugin -install mobz/elasticsearch-head
Pour savoir quels plugins sont installés et par quelle urls y accéder :
curl -s -XGET 'http://localhost:9200/_nodes?pretty' | grep plugin
rsyslog intègre une limitation soft pour ne pas pourrir les IO en cas de mass logs non voulus
Dans certains cas les valeurs par défaut sont un peu faible, suffit de les up un peu en surveillant les io disk ;)
| awk '{total = total + $1}END{print total}'
find . ! -newer /tmp/file2015 -exec ls -l --block-size=M {} \; |cut -d' ' -f5|sed 's/M//'| awk '{total = total + $1}END{print total}'
Je me demandais pourquoi le status de mes index étaient à yellow, en fait c'est tout à fait normal dans un cluster mono node :-)
Découverte sympa, même si je reste fan de rsnapshot et de ses hardlink
Si vous utilisez le fileserver de puppet et que vous gérez beaucoup de petits fichiers avec, il y a surement des optimisations à faire !
En effet pour chaque fichier, le client va demander un hash au serveur et en établissant à chaque fois une nouvelle connexion tcp... le temps perdu 2,5 secondes pour 10 fichiers..
Pour voir tout ça, rdv dans les logs du puppet master et regarder les lignes : GET /production/file_metadata pour vous donner une idée
La solution est de se passer du fileserver pour ces petits fichiers et de les inclure directement dans le catalogue, en utilisant :
content => file(path)
au lieu de source => puppet:///
Ici on est passé de 14seconde à 5,5seconde
Voxygen, éditeur de la synthèse vocale de dernière génération, expert en voix expressives, vous accompagne dans la définition de votre stratégie vocale.