# Horodatage et coupures de service - Filebeat et rsyslog
**URL:** https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774
**Category:** Discussions en français
**Created:** [November 15, 2017, 2:57pm UTC](https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774 "2017-11-15T14:57:13Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@crapoulou](https://discuss.elastic.co/u/crapoulou)
#### Post date: [November 15, 2017, 2:57pm UTC](https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774/1 "2017-11-15T14:57:13Z")
Bonjour,
**Je tente de comprendre 2 choses :**
- Comment fonctionne logstash et les shippers réagissent lorsque le service Logstash-receiver (ou -indexer- d'ailleurs) est arrêté : perte de données ?
- Comment sont horodatés les logs remontés : utilisation du TimeStamp écrit dans la ligne de log OU date de réception du log : données mal horodatées en cas de coupure ?
J'utilise notamment filebeat et rsyslog pour remonter des logs sur RedHat et CentOS.
- Je remarque que certaines lignes de logs créés manuellement n'ont pas été remontées par FileBeat.
- En arrêtant le service, les logs rsyslog sont perdus pendant la coupure de service (pour CentOS 7.1 et quelques RedHat)
- L'horodatage est bien fait avec le champ timestamp du fichier apparemment.
Pourriez-vous m'aiguiller là-dessus ?
Merci d'avance,
Crapoulou.
---
### Author:  [@Julien](https://discuss.elastic.co/u/Julien)
#### Post date: [November 24, 2017, 9:33pm UTC](https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774/2 "2017-11-24T21:33:17Z")
> [@crapoulou](#):
>
> Comment fonctionne logstash et les shippers réagissent lorsque le service Logstash-receiver (ou -indexer- d'ailleurs) est arrêté : perte de données ?
Je ne suis pas certain de ce qu'est logstash-receiver. Je supose que c'est logstash qui utilise un tcp ou udp input...
Tout va dépendre du type d'input, par exemple input UDP n'a aucun contrôle de part le protocol utilisé donc meme en fonctionement normal il pourrait y avoir de la perte de donnees, TCP comprends du controle mais si logstash est arrété il ne recevra pas de données a voir si le client TCP supportera cet arret, par contre file input utilise un fichier sincedb dont logstash enverra les donnés au moins une fois.
De meme filebeat utilise un registry file
> [@crapoulou](#):
>
> Comment sont horodatés les logs remontés : utilisation du TimeStamp écrit dans la ligne de log OU date de réception du log : données mal horodatées en cas de coupure ?
Ca va dependre de l'input et du filtre dans le fichier de configuration utilisé par logstash
La recommendation serait d'utiliser le timestamp depuis chaque ligne de log en configurant le filtre correctement
output { stdout { codec =\> rubydebug } }
> [@crapoulou](#):
>
> Je remarque que certaines lignes de logs créés manuellement n'ont pas été remontées par FileBeat.
Peu d'information pour pouvoir aider mais le fait qu'une ligne est ajoute manuellement ou pas devrait avoir aucune importance... Est-ce que la modification manuelle remplace/suprime des données au lien d'ajouter des données a la fin du fichier par exemple, ce serait l'explication la plus logique...
> [@crapoulou](#):
>
> En arrêtant le service, les logs rsyslog sont perdus pendant la coupure de service (pour CentOS 7.1 et quelques RedHat)
La recommendation pour rsyslog serait d'envoyer les logs sur le disque et utiliser filebeat pour les envoyer vers logstash
---
### Author:  [@crapoulou](https://discuss.elastic.co/u/crapoulou)
#### Post date: [November 27, 2017, 3:31pm UTC](https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774/3 "2017-11-27T15:31:09Z")
Merci beaucoup pour ce retour.
Je vais regarder tout ça.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 25, 2017, 3:31pm UTC](https://discuss.elastic.co/t/horodatage-et-coupures-de-service-filebeat-et-rsyslog/107774/4 "2017-12-25T15:31:11Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.