logstash logger
1.0.0
LogStashLogger erweitert Rubys Logger -Klasse, um direkt in Logstash zu protokollieren. Es unterstützt das Schreiben in verschiedene Ausgaben im Logstash-JSON-Format. Dies ist eine Verbesserung gegenüber dem Schreiben in eine Datei oder ein Syslog, da Logstash die strukturierten Daten direkt empfangen kann.
Kann über eine UDP- oder TCP/SSL-Verbindung direkt in einen Logstash-Listener schreiben.
Kann in eine Datei, Redis, Kafka, Kinesis, Firehose, einen Unix-Socket, Syslog, Stdout oder Stdderr schreiben.
Der Logger kann eine Zeichenfolgennachricht, einen Hash, ein LogStash::Event , ein Objekt oder eine JSON-Zeichenfolge als Eingabe annehmen.
Ereignisse werden automatisch mit Nachricht, Zeitstempel, Host und Schweregrad gefüllt.
Schreibt im Logstash-JSON-Format, unterstützt aber auch andere Formate.
Kann auf mehrere Ausgänge schreiben.
Protokollmeldungen werden gepuffert und bei Verbindungsproblemen automatisch erneut gesendet.
Lässt sich über die Konfiguration problemlos in Rails integrieren.
Fügen Sie diese Zeile zur Gemfile Ihrer Anwendung hinzu:
gem 'logstash-logger'
Und dann ausführen:
$ bundle
Oder installieren Sie es selbst als:
$ gem install logstash-logger
require 'logstash-logger'# Standardmäßig UDP bei 0.0.0.0logger = LogStashLogger.new(port: 5228)# Host und Typ (UDP oder TCP) explizit angebenudp_logger = LogStashLogger.new(type: :udp, host: 'localhost' , Port: 5228)tcp_logger = LogStashLogger.new(Typ: :tcp, Host: 'localhost', port: 5229)# Andere Arten von Loggernfile_logger = LogStashLogger.new(type: :file, path: 'log/development.log', sync: true)unix_logger = LogStashLogger.new(type: :unix, path: '/tmp/sock')syslog_logger = LogStashLogger.new(type: :syslog)redis_logger = LogStashLogger.new(Typ: :redis)kafka_logger = LogStashLogger.new(Typ: :kafka)stdout_logger = LogStashLogger.new(Typ: :stdout)stderr_logger = LogStashLogger.new(Typ: :stderr)io_logger = LogStashLogger.new(Typ: :io, io: io)# Verwenden Sie ein anderes Formattercee_logger = LogStashLogger.new(
Typ: :tcp,
Host: 'logsene-receiver-syslog.sematext.com',
Port: 514,
Formatierer: :cee_syslog)custom_formatted_logger = LogStashLogger.new(
Typ: :redis,
Formatierer: MyCustomFormatter)lambda_formatted_logger = LogStashLogger.new(
Typ: :stdout,
Formatter: ->(Schweregrad, Zeit, Programmname, Nachricht) { "[#{Programmname}] #{msg}" })ruby_default_formatter_logger = LogStashLogger.new(
Typ: :Datei,
Pfad: 'log/development.log',
formatter: ::Logger::Formatter)# Nachrichten an mehrere Ausgänge senden. Jede Ausgabe hat das gleiche Format.# Syslog kann keine Ausgabe sein, da es einen separaten Logger erfordert.multi_delegating_logger = LogStashLogger.new(
Typ: :multi_delegator,
Ausgaben: [{ Typ: :file, Pfad: 'log/development.log' },{ Typ: :udp, Host: 'localhost', Port: 5228 }
])# Nachrichten auf mehrere Ausgänge verteilen.# Funktioniert genauso wie Multi Delegator, wählt jedoch zufällig einen Ausgang aus, um jede Nachricht zu senden.balancer_logger = LogStashLogger.new(
Typ: :Balancer,
Ausgaben: [{ Typ: :udp, Host: 'host1', Port: 5228 },{ Typ: :udp, Host: 'host2', Port: 5228 }
])# Nachrichten an mehrere Logger senden.# Verwenden Sie dies, wenn Sie verschiedene Formate an verschiedene Ausgänge senden müssen.# Wenn Sie sich bei Syslog anmelden müssen, müssen Sie this.multi_logger = LogStashLogger.new( verwenden
Typ: :multi_logger,
Ausgaben: [{ Typ: :file, Pfad: 'log/development.log', Formatter: ::Logger::Formatter },{ Typ: :tcp, Host: 'localhost', Port: 5228, Formatter: :json }
])# Die folgenden Meldungen werden an den UDP-Port 5228 geschrieben:logger.info 'test'# {"message": "test", "@timestamp": "2014-05-22T09:37:19.204-07:00", "@version": "1", "severity": "INFO", "host": "[hostname]"}logger.error '{"message": "error"}'# {"message": "Fehler", "@timestamp": "2014-05-22T10:10:55.877-07:00", "@version": "1", "severity": "FEHLER", "host" :"[hostname]"}logger.debug message: 'test', foo: 'bar'# {"message": "test", "foo": "bar", "@timestamp": "2014-05-22T09:43:24.004-07:00", "@version": "1", "severity" :"DEBUG","host="[hostname]"}logger.warn LogStash::Event.new(message: 'test', foo: 'bar')# {"message": "test", "foo": "bar", "@timestamp": "2014-05-22T16:44:37.364Z", "@version": "1", "severity": "WARN ","host="[hostname]"}# Markiert logginglogger.tagged('foo') { logger.fatal('bar') }# {"message": "bar", "@timestamp": "2014-05-26T20:35:14.685-07:00", "@version": "1", "severity": "FATAL", "host" :"[hostname]","tags":["foo"]} Sie können Ihren Logstash-Logger mithilfe eines URI anstelle eines Hashs konfigurieren. Dies ist in Umgebungen wie Heroku nützlich, in denen Sie möglicherweise Konfigurationswerte aus der Umgebung lesen möchten. Das URI-Schema ist type://host:port/path?key=value . Nachfolgend finden Sie einige Beispiele für URI-Konfigurationen.
udp://localhost:5228 tcp://localhost:5229 unix:///tmp/socket file:///path/to/file redis://localhost:6379 kafka://localhost:9092 stdout:/ stderr:/
Übergeben Sie den URI wie folgt an Ihren Logstash-Logger:
# Lesen Sie den URI aus einer Umgebungsvariablenlogger = LogStashLogger.new(uri: ENV['LOGSTASH_URI'])
Damit logstash die Ereignisse korrekt empfängt und analysiert, müssen Sie einen Listener konfigurieren und ausführen, der den json_lines -Codec verwendet. Um beispielsweise Ereignisse über UDP auf Port 5228 zu empfangen:
Eingabe {
udp {host => "0.0.0.0"port => 5228codec => json_lines
}} Datei- und Redis-Eingaben sollten stattdessen den json -Codec verwenden. Weitere Informationen finden Sie in den Logstash-Dokumenten.
Weitere Konfigurationsbeispiele finden Sie im Beispielverzeichnis.
Wenn Sie TCP verwenden, besteht die Möglichkeit, beim Initialisieren ein SSL-Zertifikat zum Options-Hash hinzuzufügen.
LogStashLogger.new(Typ: :tcp, Port: 5228, ssl_certificate: „/path/to/certificate.crt“)
Das SSL-Zertifikat und der Schlüssel können mit generiert werden
openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout logstash.key -out logstash.crt
Sie können SSL auch ohne Zertifikat aktivieren:
LogStashLogger.new(Typ: :tcp, Port: 5228, ssl_enable: true)
Geben Sie einen SSL-Kontext an, um mehr Kontrolle über das Verhalten zu haben. Legen Sie beispielsweise den Verifizierungsmodus fest:
ctx = OpenSSL::SSL::SSLContext.newctx.set_params(verify_mode: OpenSSL::SSL::VERIFY_NONE)LogStashLogger.new(type: :tcp, port: 5228, ssl_context: ctx)
Für SSL ist die folgende Logstash-Konfiguration erforderlich:
Eingabe {
tcp {host => "0.0.0.0"port => 5228codec => json_linesssl_enable => truessl_cert => "/path/to/certificate.crt"ssl_key => "/path/to/key.key"
}} Die Überprüfung des Hostnamens ist standardmäßig aktiviert. Ohne weitere Konfiguration wird der an :host angegebene Hostname zur Überprüfung der Zertifikatsidentität des Servers verwendet.
Wenn Sie keinen :ssl_context oder einen falschen Wert an die Option :verify_hostname übergeben, findet keine Überprüfung des Hostnamens statt.
Überprüfen Sie den Hostnamen anhand der Option :host
ctx = OpenSSL::SSL::SSLContext.newctx.cert = '/path/to/cert.pem'ctx.verify_mode = OpenSSL::SSL::VERIFY_PEERLogStashLogger.new Typ: :tcp, Host: 'logstash.example.com' Port: 5228, ssl_context: ctx
Überprüfen Sie einen Hostnamen, der sich von der Option :host unterscheidet
LogStashLogger.new Typ: :tcp, Host: '1.2.3.4' Port: 5228, ssl_context: ctx, überprüfen_hostname: 'server.example.com'
Deaktivieren Sie die Überprüfung des Hostnamens explizit
LogStashLogger.new Typ: :tcp, Host: '1.2.3.4' Port: 5228, ssl_context: ctx, verify_hostname: false
LogStashLogger protokolliert standardmäßig ein JSON-Objekt mit dem folgenden Format.
{ „message“: „Einige Nachricht“, „@timestamp“: „2015-01-29T10:43:32.196-05:00“, „@version“: „1“, „severity“: „INFO“, „host ::Hostname} Einige Anwendungen müssen möglicherweise zusätzliche Metadaten an jede Nachricht anhängen. Das LogStash::Event kann direkt manipuliert werden, indem ein customize_event -Block in der LogStashLogger -Konfiguration angegeben wird.
config = LogStashLogger.configure do |config| config.customize_event do |event|event["other_field"] = "some_other_value" enden
Diese Konfiguration würde zu der folgenden Ausgabe führen.
{"message": "Some Message", "@timestamp": "2015-01-29T10:43:32.196-05:00", "@version": "1", "severity": "INFO", "host „: „hostname“, „other_field“: „some_other_value“}Dieser Block hat vollen Zugriff auf das Ereignis, sodass Sie Felder entfernen, vorhandene Felder ändern usw. können. Um beispielsweise den Standardzeitstempel zu entfernen:
config = LogStashLogger.configure do |config| config.customize_event do |event|event.remove('@timestamp')
enden Sie können Ereignisse auch für jeden Logger individuell anpassen, indem Sie beim Erstellen eines Loggers ein aufrufbares Objekt (Lambda oder Proc) an die Option customize_event übergeben:
LogStashLogger.new(customize_event: ->(event){ event['other_field'] = 'other_field' })Bei Geräten, die eine Verbindung zu einem Remotedienst herstellen, werden Protokollmeldungen intern gepuffert und in einem Hintergrundthread geleert. Bei einem Verbindungsproblem werden die Nachrichten im Puffer gehalten und automatisch erneut gesendet, bis die Verbindung erfolgreich ist. Ausgaben, die Batch-Schreiben unterstützen (Redis und Kafka), schreiben Protokollnachrichten in großen Mengen aus dem Puffer. Diese Funktionalität wird mithilfe eines Forks von Stud::Buffer implementiert. Sie können sein Verhalten konfigurieren, indem Sie die folgenden Optionen an LogStashLogger übergeben:
:buffer_max_items – Maximale Anzahl von Elementen, die vor dem Leeren gepuffert werden sollen. Der Standardwert ist 50.
:buffer_max_interval – Maximale Anzahl an Sekunden, die zwischen Spülvorgängen gewartet werden soll. Der Standardwert ist 5.
:drop_messages_on_flush_error – Nachrichten verwerfen, wenn ein Flush-Fehler auftritt. Der Standardwert ist „false“.
:drop_messages_on_full_buffer – Nachrichten verwerfen, wenn der Puffer voll ist. Der Standardwert ist „true“.
:sync – Puffer jedes Mal leeren, wenn eine Nachricht empfangen wird (Blockierung). Der Standardwert ist „false“.
:buffer_flush_at_exit – Nachrichten beim Beenden des Programms leeren. Der Standardwert ist „true“.
:buffer_logger – Logger zum Schreiben von Puffer-Debug-/Fehlermeldungen. Der Standardwert ist „Keine“.
Sie können die Pufferung deaktivieren, indem Sie sync = true festlegen.
Bitte beachten Sie die folgenden Vorbehalte gegenüber diesem Verhalten:
Es ist möglich, dass bei einem erneuten Versuch doppelte Protokollnachrichten gesendet werden. Bei Ausgaben wie Redis und Kafka, die in Stapeln schreiben, könnte der gesamte Stapel erneut gesendet werden. Wenn dies ein Problem darstellt, können Sie jedem Ereignis ein UUID-Feld hinzufügen, um es eindeutig zu identifizieren. Sie können dies entweder in einem customize_event -Block tun oder indem Sie den UUID-Filter von logstash verwenden.
Es ist immer noch möglich, dass Protokollnachrichten verloren gehen. Ruby erkennt ein TCP/UDP-Verbindungsproblem nicht sofort. Bei meinen Tests brauchte Ruby etwa 4 Sekunden, um zu bemerken, dass die Empfangsseite ausgefallen war, und begann, Ausnahmen auszulösen. Da Logstash-Listener über TCP/UDP empfangene Nachrichten nicht bestätigen, ist es nicht möglich zu wissen, welche Protokollnachrichten erneut gesendet werden sollen.
Wenn sync deaktiviert ist, puffert Ruby möglicherweise Daten intern, bevor es auf das E/A-Gerät schreibt. Aus diesem Grund werden Nachrichten möglicherweise nicht sofort an einen UDP- oder TCP-Socket geschrieben, obwohl der Puffer von LogStashLogger regelmäßig geleert wird.
Standardmäßig werden Nachrichten verworfen, wenn der Puffer voll ist. Dies kann passieren, wenn die Ausgabequelle zu lange nicht verfügbar ist oder Protokollmeldungen zu schnell empfangen werden. Wenn Ihre Anwendung plötzlich beendet wird (z. B. durch SIGKILL oder einen Stromausfall), geht der gesamte Puffer verloren.
Sie können die Wahrscheinlichkeit eines Nachrichtenverlusts verringern, indem Sie buffer_max_items erhöhen (damit mehr Ereignisse im Puffer gespeichert werden können) und buffer_max_interval verringern (um weniger Zeit zwischen den Löschvorgängen zu warten). Dadurch erhöht sich die Speicherbelastung Ihrer Anwendung, da sich Protokollmeldungen im Puffer ansammeln. Stellen Sie daher sicher, dass Sie Ihrem Prozess genügend Speicher zugewiesen haben.
Wenn Sie keine Nachrichten verlieren möchten, wenn der Puffer voll ist, können Sie drop_messages_on_full_buffer = false festlegen. Beachten Sie, dass alle eingehenden Protokollnachrichten blockiert werden, wenn der Puffer voll ist, was unerwünscht sein kann.
Alle Logger-Ausgänge unterstützen eine sync . Dies ist analog zur Einstellung „Synchronisierungsmodus“ für Ruby IO-Objekte. Bei Festlegung auf true wird die Ausgabe sofort geleert und nicht intern gepuffert. Normalerweise ist Pufferung für Geräte, die eine Verbindung zu einem Remote-Dienst herstellen, eine gute Sache, da sie die Leistung verbessert und die Wahrscheinlichkeit von Fehlern verringert, die sich auf das Programm auswirken. Für diese Geräte ist sync standardmäßig auf false eingestellt und es wird empfohlen, den Standardwert beizubehalten. Möglicherweise möchten Sie den Synchronisierungsmodus zu Testzwecken aktivieren, beispielsweise wenn Sie Protokollmeldungen sofort nach dem Schreiben sehen möchten.
Es wird empfohlen, den Synchronisierungsmodus für Datei- und Unix-Socket-Ausgaben zu aktivieren. Dadurch wird sichergestellt, dass Protokollnachrichten von verschiedenen Threads oder Prozessen korrekt in separate Zeilen geschrieben werden.
Weitere Einzelheiten finden Sie unter Nr. 44.
Wenn beim Schreiben einer Nachricht an das Gerät eine Ausnahme auftritt, wird die Ausnahme mithilfe eines internen Loggers protokolliert. Standardmäßig erfolgt die Protokollierung in $stderr. Sie können den Fehlerlogger ändern, indem Sie LogStashLogger.configuration.default_error_logger festlegen oder Ihr eigenes Logger-Objekt im Konfigurationsschlüssel :error_logger übergeben, wenn Sie einen LogStashLogger instanziieren.
LogStashLogger bietet Unterstützung für die Logger-Stummschaltung im Rails-Stil. Die Implementierung wurde aus Rails extrahiert, weist jedoch keine Abhängigkeiten auf und kann daher außerhalb einer Rails-App verwendet werden. Die Schnittstelle ist die gleiche wie in Rails:
logger.silence(temporary_level) tun ...Ende
Standardmäßig erstellt LogStashLogger einen Logger, der die in Ruby integrierte Logger Klasse erweitert. Wenn Sie eine andere Logger-Implementierung benötigen, können Sie eine andere Klasse verwenden, indem Sie die Klasse mit der Option logger_class übergeben.
Beachten Sie, dass für Syslog die Klasse Syslog::Logger erforderlich ist und nicht geändert werden kann.
Unterstützt Rails 4.2 und 5.x.
Standardmäßig wird jede Rails-Protokollnachricht im LogStash::Event JSON-Format in logstash geschrieben.
Probieren Sie für minimale, strukturiertere Logstash-Ereignisse eines der folgenden Juwelen aus:
lograge
Yarder
Derzeit geben diese Gems einen JSON-String aus, den LogStashLogger dann analysiert. Zukünftige Versionen dieser Gems könnten möglicherweise eine tiefere Integration mit LogStashLogger haben (z. B. durch direktes Schreiben von LogStash::Event -Objekten).
Fügen Sie Folgendes zu Ihrer config/environments/production.rb hinzu:
# Optional, Rails setzt den Standardwert auf :infoconfig.log_level = :debug# Optional, Rails 4 ist in der Entwicklung standardmäßig auf „true“ und in der Produktion auf „false“ eingestelltconfig.autoflush_log = true# Optional, verwenden Sie zum Konfigurieren einen URI. Nützlich bei Herokuconfig.logstash.uri = ENV['LOGSTASH_URI']# Optional. Standardmäßig ist :json_lines. Wenn es mehrere Ausgaben gibt, # verwenden sie alle dasselbe formatter.config.logstash.formatter = :json_lines# Optional, der Logger, in dem Schreibfehler protokolliert werden. Standardmäßig wird bei $stderrconfig.logstash.error_logger = Logger.new($stderr)# protokolliert. Optional, maximale Anzahl von Elementen, die vor dem Leeren gepuffert werden sollen. Der Standardwert ist 50config.logstash.buffer_max_items = 50#. Optional, maximale Anzahl an Sekunden, die zwischen den Spülvorgängen gewartet werden soll. Standardmäßig ist 5config.logstash.buffer_max_interval = 5# Optional, Nachricht löschen, wenn ein Verbindungsfehler auftritt. Standardmäßig falseconfig.logstash.drop_messages_on_flush_error = false# Optional, Nachrichten verwerfen, wenn der Puffer voll ist. Der Standardwert ist trueconfig.logstash.drop_messages_on_full_buffer = true
# Optional, standardmäßig ist '0.0.0.0'config.logstash.host = 'localhost'# Optional, standardmäßig ist :udp.config.logstash.type = :udp# Erforderlich, der Port zum Herstellen einer Verbindung mitconfig.logstash.port = 5228
# Optional, Standardwert ist '0.0.0.0'config.logstash.host = 'localhost'# Erforderlich, der Port für die Verbindung mitconfig.logstash.port = 5228# Erforderlichconfig.logstash.type = :tcp# Optional, aktiviert SSLconfig.logstash. ssl_enable = true
# Requiredconfig.logstash.type = :unix# Requiredconfig.logstash.path = '/tmp/sock'
Wenn Sie Ruby 1.9 verwenden, fügen Sie Syslog::Logger v2 zu Ihrer Gemfile hinzu:
gem 'SyslogLogger', '2.0'
Wenn Sie Ruby 2+ verwenden, ist Syslog::Logger bereits in die Standardbibliothek integriert.
# Requiredconfig.logstash.type = :syslog# Optional. Standardmäßig ist 'ruby'config.logstash.program_name = 'MyApp'# Optionale Standard-Einrichtungsebene. Funktioniert nur in Ruby 2+config.logstash.facility = Syslog::LOG_LOCAL0
Fügen Sie den Redis-Gem zu Ihrer Gemfile hinzu:
gem 'redis'
# Erforderlichconfig.logstash.type = :redis# Optional, standardmäßig wird die Liste „logstash“ verwendetconfig.logstash.list = 'logstash'# Alle anderen Optionen werden an den Redis-Client übergeben# Zu den unterstützten Optionen gehören Host, Port, Pfad und Passwort , URL# Beispiel:# Optional, Redis verwendet standardmäßig localhostconfig.logstash.host = 'localhost'# Optional, Redis verwendet standardmäßig Port 6379config.logstash.port = 6379
Fügen Sie den Poseidon-Edelstein zu Ihrer Gemfile hinzu:
gem 'poseidon'
# Erforderlichconfig.logstash.type = :kafka# Optional, standardmäßig wird „logstash“ verwendet. topicconfig.logstash.path = 'logstash'# Optional, standardmäßig wird „logstash-logger“ verwendet. Producerconfig.logstash.producer = 'logstash-logger '# Optional, wird standardmäßig localhost:9092 sein. host/portconfig.logstash.hosts = ['localhost:9092']# Optional, wird standardmäßig verwendet auf 1s backoffconfig.logstash.backoff = 1
Fügen Sie das aws-sdk-Gem zu Ihrer Gemfile hinzu:
# aws-sdk >= 3.0 gem 'aws-sdk-kinesis' # aws-sdk < 3.0 gem 'aws-sdk'
# Erforderlichconfig.logstash.type = :kinesis# Optional, standardmäßig „logstash“ streamconfig.logstash.stream = „my-stream-name“# Optional, standardmäßig „us-east-1“config.logstash.aws_region = 'us-west-2'# Optional, wird standardmäßig die AWS_ACCESS_KEY_ID-Umgebungsvariableconfig.logstash.aws_access_key_id = verwendet 'ASKASKHLD12341'# Optional, wird standardmäßig die Umgebungsvariable AWS_SECRET_ACCESS_KEY verwendetconfig.logstash.aws_secret_access_key = 'ASKASKHLD1234123412341234'
Fügen Sie das aws-sdk-Gem zu Ihrer Gemfile hinzu:
# aws-sdk >= 3.0 gem 'aws-sdk-firehose' # aws-sdk < 3.0 gem 'aws-sdk'
# Erforderlichconfig.logstash.type = :firehose# Optional, wird standardmäßig die „Logstash“-Lieferung verwendet streamconfig.logstash.stream = 'my-stream-name'# Optional, wird standardmäßig die AWS-Standardregionskonfiguration verwendet chainconfig.logstash.aws_region = ' us-west-2'# Optional, standardmäßig wird der AWS-Standard-Anmeldeinformationsanbieter verwendet. chainconfig.logstash.aws_access_key_id = 'ASKASKHLD12341'# Optional, wird standardmäßig der AWS-Standard-Anmeldeinformationsanbieter chainconfig.logstash.aws_secret_access_key = 'ASKASKHLD1234123412341234' verwendet.
# Erforderlichconfig.logstash.type = :file# Optional, standardmäßig Rails log pathconfig.logstash.path = 'log/produktion.log'
# Requiredconfig.logstash.type = :io# Requiredconfig.logstash.io = io
# Requiredconfig.logstash.type = :multi_delegator# Requiredconfig.logstash.outputs = [
{Typ: :Datei,Pfad: 'log/produktion.log'
},
{Typ: :udp,Port: 5228,Host: 'localhost'
}] # Erforderlichconfig.logstash.type = :multi_logger# Erforderlich. Jeder Logger kann seinen eigenen formatter.config.logstash.outputs = [
{type: :file,path: 'log/produktion.log',formatter: ::Logger::Formatter
},
{Typ: :udp,Port: 5228,Host: 'localhost'
}]In Webanwendungen können Sie mithilfe der RequestStore-Middleware Daten aus HTTP-Anfragen (z. B. Header) protokollieren. Das folgende Beispiel geht von Rails aus.
# in Gemfilegem 'request_store'
# in application.rbLogStashLogger.configure |config| ausführen config.customize_event do |event|event["session_id"] = RequestStore.store[:load_balancer_session_id] enden
# in app/controllers/application_controller.rbbefore_filter :track_load_balancer_session_iddef track_load_balancer_session_id RequestStore.store[:load_balancer_session_id] = request.headers["X-LOADBALANCER-SESSIONID"]end
Wenn Ihre Anwendung verzweigt (was bei vielen Webservern üblich ist), müssen Sie die Bereinigung der Ressourcen auf Ihren LogStashLogger-Instanzen verwalten. Hierzu steht die Instanzmethode #reset zur Verfügung. Hier ist eine Beispielkonfiguration für mehrere gängige Webserver, die mit Rails verwendet werden:
Passagier:
::PhusionPassenger.on_event(:starting_worker_process) macht |forked| Rails.logger.resetend
Puma:
# In config/puma.rbon_worker_boot tun Rails.logger.resetend
Einhorn
# Führen Sie in config/unicorn.rbafter_fork |server, worker| aus Rails.logger.resetend
Bestätigt für die Zusammenarbeit mit:
MRT Ruby 2,2 - 2,5
JRuby 9.x
Rubinius
Ruby-Versionen < 2.2 sind EOL und werden nicht mehr unterstützt.
Es hängt von Ihren spezifischen Anforderungen ab, aber die meisten Anwendungen sollten die Standardeinstellung (UDP) verwenden. Hier sind die Vor- und Nachteile jedes Typs:
UDP ist schneller als TCP, da es asynchron ist (Fire-and-Forget). Dies bedeutet jedoch, dass Protokollnachrichten gelöscht werden könnten. Für viele Anwendungen ist das in Ordnung.
TCP überprüft, ob jede Nachricht über eine bidirektionale Kommunikation empfangen wurde. Es unterstützt auch SSL für die sichere Übertragung von Protokollnachrichten über ein Netzwerk. Dies kann dazu führen, dass Ihre App langsamer wird, wenn der TCP-Listener stark ausgelastet ist.
Eine Datei ist einfach zu verwenden, aber Sie müssen sich Sorgen machen, dass die Protokolle rotieren und nicht genügend Speicherplatz zur Verfügung steht.
Das Schreiben auf einen Unix-Socket ist schneller als das Schreiben auf einen TCP- oder UDP-Port, funktioniert aber nur lokal.
Das Schreiben in Redis eignet sich gut für verteilte Setups, die Unmengen an Protokollen generieren. Sie haben jedoch einen weiteren beweglichen Teil und müssen sich Sorgen machen, dass Redis nicht mehr über genügend Speicher verfügt.
Das Schreiben in stdout wird nur zu Debugzwecken empfohlen.
Für eine detailliertere Diskussion von UDP vs. TCP empfehle ich die Lektüre dieses Artikels: UDP vs. TCP
Wenn Sie ein Gerät verwenden, das von einem Ruby-IO-Objekt unterstützt wird (z. B. eine Datei, ein UDP-Socket oder ein TCP-Socket), beachten Sie bitte, dass Ruby seinen eigenen internen Puffer behält. Trotz der Tatsache, dass LogStashLogger Nachrichten puffert und regelmäßig löscht, können die in das IO-Objekt geschriebenen Daten von Ruby intern auf unbestimmte Zeit gepuffert werden und möglicherweise erst geschrieben werden, wenn das Programm beendet wird. Wenn Sie dies stört oder Sie Protokollmeldungen sofort sehen möchten, besteht Ihre einzige Möglichkeit darin, die Option sync: true festzulegen.
Ihre Anwendung versucht wahrscheinlich, Daten zu protokollieren, die nicht gültig codiert sind. In diesem Fall löst die Standard-JSON-Bibliothek von Ruby eine Ausnahme aus. Möglicherweise können Sie dieses Problem beheben, indem Sie einen anderen JSON-Encoder wie Oj austauschen. Verwenden Sie das Gem oj_mimic_json, um Oj für die JSON-Generierung zu verwenden.
Heroku empfiehlt, den Rails_12-Faktor zu installieren, damit Protokolle an STDOUT gesendet werden. Leider überschreibt dies LogStashLogger und verhindert, dass Protokolle an ihr konfiguriertes Ziel gesendet werden. Die Lösung besteht darin, rails_12factor aus Ihrer Gemfile zu entfernen.
Dies ist höchstwahrscheinlich kein Problem mit LogStashLogger, sondern eher ein anderes Juwel, das die Protokollebene von Rails.logger ändert. Dies ist besonders wahrscheinlich, wenn Sie einen Thread-Server wie Puma verwenden, da Gems die Protokollebene von Rails.logger häufig auf nicht threadsichere Weise ändern. Weitere Informationen finden Sie unter Nr. 17.
Wenn Sie die UDP-Ausgabe verwenden und in einen Logstash-Listener schreiben, stoßen Sie höchstwahrscheinlich auf einen Fehler in der UDP-Implementierung des Logstash-Listeners. Derzeit ist keine Lösung bekannt. Weitere Informationen finden Sie unter Nr. 43.
Ein bekannter Nachteil der Verwendung von TCP oder UDP ist die Beschränkung der Gesamtnachrichtengröße auf 65535 Byte. Um dieses Problem zu umgehen, müssen Sie die Nachricht kürzen, indem Sie die maximale Nachrichtengröße festlegen:
LogStashLogger.configure tun |config| config.max_message_size = 2000end
Dadurch wird nur das message des LogStash-Ereignisses abgeschnitten. Stellen Sie daher sicher, dass Sie die maximale Nachrichtengröße deutlich unter 65535 Bytes festlegen, um Platz für andere Felder zu schaffen.
Rails 3.2, MRI Ruby < 2.2 und JRuby 1.7 werden nicht mehr unterstützt, da sie EOL haben. Wenn Sie eine ältere Version von Ruby verwenden, müssen Sie 0.24 oder niedriger verwenden.
Der source wurde durch host ersetzt, um besser mit dem neuesten Logstash übereinzustimmen.
Der Konstruktor (host, port, type) wurde zugunsten eines Options-Hash-Konstruktors veraltet.
LogStash::Event verwendet das v1-Format ab Version 1.2+. Wenn Sie Version 1 verwenden, müssen Sie LogStashLogger Version 0.4+ installieren. Dies ist nicht abwärtskompatibel mit dem alten LogStash::Event v1.1.5, das das v0-Format verwendet.
Frühere Versionen dieses Gems (<= 0.2.1) implementierten nur eine TCP-Verbindung. Neuere Versionen (>= 0.3) implementieren auch UDP und verwenden es als neuen Standard. Bitte beachten Sie, dass Sie ein zusätzliches Argument hinzufügen sollten, wenn Sie den Standardkonstruktor verwenden und dennoch TCP benötigen:
# Jetzt standardmäßig UDP anstelle von TCPlogger = LogStashLogger.new('localhost', 5228)# Geben Sie explizit TCP anstelle von UDPlogger an = LogStashLogger.new('localhost', 5228, :tcp)David Butler
pctj101
Gary Rennie
Nick Ethier
Arron Mabrey
Jan Schulte
Kurt Preston
Chris Blatchley
Felix Bechstein
Wadim Kasakow
Anil Rhemtulla
Nikita Vorobei
Feuerjunge1919
Mike Gunderloy
Vitaly Gorodetsky
Courtland Caldwell
Bibek Shrestha
Alex Ianus
Craig Read
glaszig
Bin Lan
Joao Fernandes
CoolElvis
Sergej Pjankow
Alec Hoey
Alexey Krasnoperov
Gabriel de Oliveira
Vladislav Syabruk
Matus Vacula
Gabel es
Erstellen Sie Ihren Feature-Zweig ( git checkout -b my-new-feature )
Übernehmen Sie Ihre Änderungen ( git commit -am 'Add some feature' )
Zum Zweig pushen ( git push origin my-new-feature )
Erstellen Sie eine neue Pull-Anfrage
