Perfect video for me to share with my coworkers who don't know anything about open telemetry, thank you! Im looking forward to seeing all the specialized videos on the various collector elements
Oh man you have amazing content! thank you so much for this explanation and looking forward to more! The way you broke down the collector and in the end introduced connectors and extensions is brilliant. Keep it up
Nice explaination: question though, when we say we can have multiple receivers (4:18), are you saying that OT collector is replaced by prometheus? as if I understand, OT collector receives data, processes (so that Prometheus can understand) and exports it. Later, prometheus will collect the data via pull.
Prometheus can be understood as two different things. 1) The Prometheus data syntax. By this I mean the syntax of the lines of code that describe the metrics + the fact that metrics usually live at a standard endpoint. 2) The Prometheus "product". By this I mean the software that retrieves (or accepts) metrics, stores them, visualises them etc. Here I'm explaining that the OTEL collector (instead of Prometheus) can scrape the metrics (which are formatted like 1) and send them to a backend which isn't prometheus (2). My point about multiple receivers: Prometheus (the product) only deals with metrics. It doesn't do metrics or traces. But the OTEL collector process all of those signals. So... If your backend is capable, you can send your metrics, logs and traces to the same place.
Hi, Thanks for the east explanation for the topics. I have one question , what would happen if we leave the processor part empty ? like would the data flowing into the metrics would be correct or not ?
Processors are optional. If they aren't specified, nothing happens meaning the data is not altered in any way. What you send in is what comes out again.
Does it mean it’s like fluentd ? I’ve been looking into logging I’ve got some backend api and a database I would like to have a webpage where I could track logs I’ve come across elk stack and I’ve now know that Logstash is a way to centralized all logs as well as fluentd but I’ve been seeing open telemetry popping of here and there during my search but I’m not sure what it is everything is so abstract that I’m seeing
The collector and fluentd (sidetone, I'd recommend fluentbit over fluentd) are both the middleware. OpenTelemetry is not a backend (storage) for Observability data (logs, metrics, traces etc.) so you'll still need a backend system (ELK, Dynatrace, Datadog, Opensearch etc.). Would it be helpful if I made a short explainer viideo on "what is OpenTelemetry?"
@@agardnerityes I guess that’ll be nice but I don’t know if a developer would find it useful or know what’s the use case I guess this is a very deep Devops thing which I am not I just wanted something to track logs in a nice way since I’m using docker and can’t keep running dog logs command I think I’ve been seeing this fluentbit thing as well but they aren’t a lot of resources like fluentd I didn’t even know this term flying around called observability but I guess it’s part of a broader name given to do certain things Thank you very much for your response also can I know which is the most simplest solution for my use case I just want to have a way of viewing my logs and nothing to heavy or resource intensive I’m currently dabbling with this elk thing and it seems packed with a lot of stuffs I don’t need and understand
Very good explanation of the core components of the OpenTelemtry Collector! I'm already looking forward to new content on this!
Excellent content with clarity and nice pace.
Perfect video for me to share with my coworkers who don't know anything about open telemetry, thank you!
Im looking forward to seeing all the specialized videos on the various collector elements
Oh man you have amazing content! thank you so much for this explanation and looking forward to more! The way you broke down the collector and in the end introduced connectors and extensions is brilliant. Keep it up
Awesome, thank you!
Best video and best explanation! thanks for the nice explanation.
Very well explained 👍
Thank you 🙂
I'm new to open telemetry and this was very informative
So glad you found it useful.
This was a very good video !
Thank you!
Nice explaination: question though, when we say we can have multiple receivers (4:18), are you saying that OT collector is replaced by prometheus? as if I understand, OT collector receives data, processes (so that Prometheus can understand) and exports it. Later, prometheus will collect the data via pull.
Prometheus can be understood as two different things. 1) The Prometheus data syntax. By this I mean the syntax of the lines of code that describe the metrics + the fact that metrics usually live at a standard endpoint. 2) The Prometheus "product". By this I mean the software that retrieves (or accepts) metrics, stores them, visualises them etc.
Here I'm explaining that the OTEL collector (instead of Prometheus) can scrape the metrics (which are formatted like 1) and send them to a backend which isn't prometheus (2).
My point about multiple receivers: Prometheus (the product) only deals with metrics. It doesn't do metrics or traces. But the OTEL collector process all of those signals. So... If your backend is capable, you can send your metrics, logs and traces to the same place.
Hi,
Thanks for the east explanation for the topics.
I have one question , what would happen if we leave the processor part empty ? like would the data flowing into the metrics would be correct or not ?
Processors are optional. If they aren't specified, nothing happens meaning the data is not altered in any way. What you send in is what comes out again.
Does it mean it’s like fluentd ? I’ve been looking into logging I’ve got some backend api and a database I would like to have a webpage where I could track logs I’ve come across elk stack and I’ve now know that Logstash is a way to centralized all logs as well as fluentd but I’ve been seeing open telemetry popping of here and there during my search but I’m not sure what it is everything is so abstract that I’m seeing
The collector and fluentd (sidetone, I'd recommend fluentbit over fluentd) are both the middleware. OpenTelemetry is not a backend (storage) for Observability data (logs, metrics, traces etc.) so you'll still need a backend system (ELK, Dynatrace, Datadog, Opensearch etc.). Would it be helpful if I made a short explainer viideo on "what is OpenTelemetry?"
@@agardnerityes I guess that’ll be nice but I don’t know if a developer would find it useful or know what’s the use case I guess this is a very deep Devops thing which I am not
I just wanted something to track logs in a nice way since I’m using docker and can’t keep running dog logs command I think I’ve been seeing this fluentbit thing as well but they aren’t a lot of resources like fluentd I didn’t even know this term flying around called observability but I guess it’s part of a broader name given to do certain things
Thank you very much for your response also can I know which is the most simplest solution for my use case I just want to have a way of viewing my logs and nothing to heavy or resource intensive I’m currently dabbling with this elk thing and it seems packed with a lot of stuffs I don’t need and understand
cool story