logstash-logback-encoder
b3-propagation
Our great sponsors
logstash-logback-encoder | b3-propagation | |
---|---|---|
8 | 3 | |
2,386 | 516 | |
1.2% | 1.7% | |
5.2 | 2.7 | |
21 days ago | 2 months ago | |
Java | ||
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
logstash-logback-encoder
- Tracing: Structured Logging, but better in every way
-
Do you have a guideline on logging
I use the logstash json format.
-
How to do JSON logging in Scala?
We're using https://github.com/logfellow/logstash-logback-encoder with logback (on Play Framework, but should work fine on Lambda as well).
-
JSON logging for JSON REST services vs performance
For those interested in the details, I've created an example implementation based on Spring-flavoured REST and Logbook+logstash-logback-encoder within my own json-log-filter project for PoC / reference.
-
Echopraxia, a better Java Logging API
what's the difference to https://github.com/logfellow/logstash-logback-encoder ??
-
Is it reasonable to transform log4jlogs in via a configuration file?
Don't use filebeat. Filebeat is for systems that you cannot change logging for. Push logs directly to logstash via logstash appender. Since I'm mainly logback user, there's one directly by logstash at https://github.com/logstash/logstash-logback-encoder. Quick search indicates that there's https://github.com/viskan/logstash-appender/ for log4j also and it seems it also supports MDC abuse as indicated by https://github.com/viskan/logstash-appender/blob/master/src/main/java/com/viskan/log4j/logstash/appender/LogstashAppender.java#L256. By abusing the MDC you won't need to write a processing pattern in logstash to extract metadata from giant blob line as each key in MDC will get assigned additional value, making your records in elastic search more useful.
-
Java Spring Application logging to WS endpoint
You can use the Logstash Logback encooder. You mentioned Elk, so there must be a Logstash running somewhere you can connect to with this appender
-
Spring Cloud Sleuth in action
We need to add traceId and spanId values to the application log. In production we would use the logstash-logback-encoder to generate logs in JSON format and send them to an ELK but for the demo we use this plain text logback layout:
b3-propagation
-
OpenTelemetry in 2023
I've been playing with OTEL for a while, with a few backends like Jaeger and Zipkin, and am trying to figure out a way to perform end to end timing measurements across a graph of services triggered by any of several events.
Consider this scenario: There is a collection of services that talk to one another, and not all use HTTP. Say agent A0 makes a connection to agent A1, this is observed by service S0 which triggers service S1 to make calls to S2 and S3, which propagate elsewhere and return answers.
If we limit the scope of this problem to services explicitly making HTTP calls to other services, we can easily use the Propagators API [1] and use X-B3 headers [2] to propagate the trace context (trace ID, span ID, parent span ID) across this graph, from the origin through to the destination and back. This allows me to query the metrics collector (Jaeger or Zipkin) using this trace ID, look at the timestamps originating at the various services and do a T_end - T_start to determine the overall time taken by one call for a round trip across all the related services.
However, this breaks when a subset of these functions cannot propagate the B3 trace IDs for various reasons (e.g., a service is watching a specific state and acts when the state changes). I've been looking into OTEL and other related non-OTEL ways to capture metrics, but it appears there's not much research into this area though it does not seem like a unique or new problem.
Has anyone here looked at this scenario, and have you had any luck with OTEL or other mechanisms to get results?
[1] https://opentelemetry.io/docs/specs/otel/context/api-propaga...
[2] https://github.com/openzipkin/b3-propagation
[3] https://www.w3.org/TR/trace-context/
-
OpenTelemetry and Istio: Everything you need to know
(Note that OpenTelemetry uses, by default, the W3C context propagation specification, while Istio uses the B3 context propagation specification β this can be modified).
-
Spring Cloud Sleuth in action
The default format for context propagation is B3 so we use headers X-B3-TraceId and X-B3-SpanId
What are some alternatives?
spring-cloud-sleuth-in-action - π Spring Cloud Sleuth in Action
trace-context-w3c - W3C Trace Context purpose of and what kind of problem it came to solve.
logback-gelf - Logback appender for sending GELF messages with zero additional dependencies.
zipkin - Zipkin is a distributed tracing system
logstash-appender - A log4j appender that sends raw JSON directly to Logstash
odigos - Distributed tracing without code changes. π Instantly monitor any application using OpenTelemetry and eBPF
logback-android - πThe reliable, generic, fast and flexible logging framework for Android
community - OpenTelemetry community content
kafkacat - Generic command line non-JVM Apache Kafka producer and consumer [Moved to: https://github.com/edenhill/kcat]
oteps - OpenTelemetry Enhancement Proposals