diff --git a/.github/workflows/check-spelling.yml b/.github/workflows/check-spelling.yml index 1c247eabffa3..7e70bf3a22ca 100644 --- a/.github/workflows/check-spelling.yml +++ b/.github/workflows/check-spelling.yml @@ -9,7 +9,7 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - - uses: streetsidesoftware/cspell-action@v5 + - uses: streetsidesoftware/cspell-action@v6 with: # Files should be consistent with check:spelling files files: | diff --git a/.github/workflows/pr-actions.yml b/.github/workflows/pr-actions.yml index dfc5319e81b6..e4df9645fbb8 100644 --- a/.github/workflows/pr-actions.yml +++ b/.github/workflows/pr-actions.yml @@ -31,7 +31,7 @@ jobs: run: | PR_ACTION=$(echo $COMMENT | grep -oP '/fix:\K\w+') echo "Action is $PR_ACTION" - ACTION_NAMES="format|submodules|refcache|all" + ACTION_NAMES="all|dict|filenames|format|markdown|refcache|submodules" if [[ ! "$PR_ACTION" =~ ^($ACTION_NAMES)$ ]]; then echo "Invalid action name: $PR_ACTION" echo "Action name should be one of: $ACTION_NAMES" @@ -72,7 +72,7 @@ jobs: all|refcache) npm install --omit=optional ;& - format|submodules) + dict|filenames|format|markdown|submodules) npm run fix:$PR_ACTION ;; esac diff --git a/content/en/blog/2023/end-user-discussions-03.md b/content/en/blog/2023/end-user-discussions-03.md index 7b0e6a431bc7..3e7d068c8115 100644 --- a/content/en/blog/2023/end-user-discussions-03.md +++ b/content/en/blog/2023/end-user-discussions-03.md @@ -186,7 +186,7 @@ agent to the host metrics receiver for infrastructure monitoring. **A:** It depends on the use cases: -- [Auto instrumentation](/docs/concepts/instrumentation/automatic/) options are +- [Auto instrumentation](/docs/concepts/instrumentation/zero-code/) options are maturing in OTel; for example, the Java JAR agent takes care of instrumenting [most libraries](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks) that are used by applications. Auto-instrumentation is also available for diff --git a/content/en/blog/2023/logs-collection/index.md b/content/en/blog/2023/logs-collection/index.md index a4e3c0dc16fa..7408c916fad2 100644 --- a/content/en/blog/2023/logs-collection/index.md +++ b/content/en/blog/2023/logs-collection/index.md @@ -425,7 +425,7 @@ extend Yoda's code to do the following: 1. Once you have traces and logs ingested in a backend, try to correlate these two telemetry signal types in the backend along with a frontend such as Grafana. -1. Use [Automatic Instrumentation](/docs/concepts/instrumentation/automatic/) to +1. Use [Automatic Instrumentation](/docs/concepts/instrumentation/zero-code/) to further enrich telemetry. The community is currently working on the [Events API diff --git a/content/en/blog/2024/demo-skyscanner/index.md b/content/en/blog/2024/demo-skyscanner/index.md new file mode 100644 index 000000000000..3b1ea41fe21c --- /dev/null +++ b/content/en/blog/2024/demo-skyscanner/index.md @@ -0,0 +1,109 @@ +--- +title: + "Making observability fun: How we increased engineers' confidence in incident + management using a game" +linkTitle: Skyscanner using OTel Demo +date: 2024-02-26 +author: >- + [Jordi Bisbal Ansaldo](https://github.com/jordibisbal8) (Skyscanner) +cSpell:ignore: Ansaldo Bisbal Jordi runbooks Skyscanner upskilled Yankova +--- + +At [Skyscanner](https://www.skyscanner.net), as in many organizations, teams +tend to follow specific runbooks for individual failure modes. With modern and +complex distributed systems, this has the downside of most of the errors being +unknowns, which makes runbooks only partially applicable. + +After migrating our telemetry data to the OpenTelemetry standards at Skyscanner, +we now have richer instrumentation and can rely on observability directly. As a +result, we are ready to adopt a new +[observability mindset](https://charity.wtf/2019/09/20/love-and-alerting-in-the-time-of-cholera-and-observability/), +which requires training our engineers to work effectively with the new +ecosystem. This allows them to react efficiently to any known or unknown issues, +even under pressure. + +To achieve this, we believe that the best way to gain knowledge isn’t through +one-time viewings of documents or videos. Instead, it’s through practical +exercises that include situations with never-before-seen (or at least rarely +seen) problems. This helps the company reduce the time to mitigate an issue +(TTM), which starts when a first responder acknowledges the incident, until +users stop suffering from the incident. + +## Environment + +To begin with, we need to set up an environment that demonstrates the best +practices for monitoring and debugging using OpenTelemetry instrumentation and +observability. For this, we propose the use of the official +[OpenTelemetry Demo](/docs/demo/), which is a realistic example of a distributed +system called Astronomy Shop. Thanks to the +[OpenTelemetry Protocol](/docs/specs/otlp/) (OTLP), it allows us to simply point +the standard OTLP exporter in the Collector to +[New Relic](https://newrelic.com/), our chosen observability platform at +Skyscanner which, like other platforms, is fully embracing open standards to +ingest telemetry data. + +This system contains regressions that can be injected into the platform and +helps us demonstrate the importance of Service Levels Objectives (SLOs), +tracing, logs, metrics, etc. For instance, we can observe traffic flow through +various components, as shown in the image below. Since part of the OpenTelemetry +ecosystem is open source, we can easily introduce any new features that will be +reviewed by OpenTelemetry contributors. + +![Distributed tracing example in Astronomy shop](tracing-example.png) + +## Observability game day + +Once the environment is set up, we can introduce the Observability Game Day, an +initiative based on the Wheel of Misfortune practices that Google uses and +describes in the [Site Reliability Engineering book](https://sre.google/books/). + +This game simulates a production incident, where a moderator known as the game +master (GM) conducts the session and someone from the audience spins the wheel +and explains an incident or outage. The participants are then divided into teams +and tasked with identifying and resolving the issue as quickly as possible. If +the solution is not optimal, the GM can help by introducing a new tool or view, +which gives a different perspective on how to tackle the incident (knowledge +sharing). This exercise can be repeated multiple times for different incidents. + +![Wheel of misfortune example](wheel.png) + +## Results + +The Observability Game Day has already been completed by multiple Skyscanner +teams, where each team observability expert (ambassador) runs the session. The +participants have given extremely positive feedback, where 90% of the responders +say that after the Game Day, they feel more confident debugging production +systems and would love to have further sessions. + +- Hugely valuable to run against real services and to compare and contrast + different debugging methods. I'm certain everyone, regardless of skill level, + will have got something out of the session - I know I did! Thank you for + taking the time to set this up and promoting it for us - + [Dominic Fraser](https://github.com/dominicfraser) (Senior Software Engineer) +- It is a really great (company-wide) initiative to get people upskilled in + observability and OpenTelemetry/New Relic and I personally found it very + useful, as well as a lot of fun! :D - Polly Yankova (Software Engineer) + +In addition, we learned that: + +1. OTLP makes it incredibly simple to integrate a standard application with an + observability vendor. Just point it to the right endpoint and job done. +2. Our winning teams relied primarily on tracing data to analyze regressions + that helped them understand the root cause faster. Tracing FTW! +3. Front-end engineers found the Game Day lacked focus on client-side + observability, so we decided to contribute upstream (see next steps below). + This was my first contribution to the project, and it was a great experience! + Maintainers were very welcoming and helped me to test and release. Thanks! + +## Next steps + +The next action is to run sessions for all the engineering teams in the company +and convert them into a Skyscanner learning course. This way, the content can be +used during the onboarding process for new joiners or even reviewed at any time +as a refresher for those who have been in the company longer. In addition, after +observing common feedback, we identified that it would be beneficial to extend +the current incidents to include more front-end-specific ones, such as incidents +triggered by browser traffic. To achieve this, we have contributed to the +OpenTelemetry Demo and enabled these features for other interested parties. For +more information, please have a look at the +[raised PR](https://github.com/open-telemetry/opentelemetry-demo/pull/1345). diff --git a/content/en/blog/2024/demo-skyscanner/tracing-example.png b/content/en/blog/2024/demo-skyscanner/tracing-example.png new file mode 100644 index 000000000000..b16759d9bab3 Binary files /dev/null and b/content/en/blog/2024/demo-skyscanner/tracing-example.png differ diff --git a/content/en/blog/2024/demo-skyscanner/wheel.png b/content/en/blog/2024/demo-skyscanner/wheel.png new file mode 100644 index 000000000000..45a1ca8c019f Binary files /dev/null and b/content/en/blog/2024/demo-skyscanner/wheel.png differ diff --git a/content/en/blog/2024/kubecon-eu.md b/content/en/blog/2024/kubecon-eu.md new file mode 100644 index 000000000000..3438e7670834 --- /dev/null +++ b/content/en/blog/2024/kubecon-eu.md @@ -0,0 +1,147 @@ +--- +title: + Join us for OpenTelemetry Talks and Activities at KubeCon + CloudNativeCon + Europe 2024 +linkTitle: KubeCon EU '24 +date: 2024-02-28 +# prettier-ignore +cSpell:ignore: Aiven Alexandre Anusha Arbiv Beemer Benedikt Blanco Bongartz Chekuri Coralogix Cosmonic Dyrmishi Jiekun Joonas Kanal Kolachala Kowall Machado Magno Marcin Matej Mirabella Narapureddy Nenashev Oleg Oluwalolope Outshift Pismo Purvi Quwan Reddy Ridwan Rollouts Ryanair Skyscanner Sodkiewicz Soluções Srikanth Tecnológicas Yosef +author: '[Severin Neumann](https://github.com/svrnm) (Cisco)' +--- + +The OpenTelemetry project maintainers, members of the governance committee, and +technical committee are thrilled to be at [KubeCon + CloudNativeCon Europe][] +and at the co-located +[Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/) +in Paris from March 19 - 22, 2024. + +Read on to learn about all the things related OpenTelemetry during KubeCon. + +This post may be updated as we receive notice of other activities, please check +it again right before KubeCon! + +## KubeCon Talks and Maintainer Sessions + +- **[OpenTelemetry: Project Updates, Next Steps, and AMA](https://sched.co/1Yhf8)**
+ by Severin Neumann, Cisco; Austin Parker, Honeycomb; Trask Stalnaker, + Microsoft; Daniel Gomez Blanco, Skyscanner; Alolita Sharma, Apple
+ Wednesday, March 20 • 11:15 - 11:50 +- **[Distributed Tracing with Jaeger and OpenTelemetry](https://sched.co/1YhfT)**
+ by Pavol Loffay, Red Hat & Jonah Kowall, Aiven
Wednesday, March 20 • + 12:10 - 12:45 +- **[Disintegrated Telemetry: The Pains of Monitoring Asynchronous Workflows](https://sched.co/1YeNV)**
+ by Johannes Tax, Grafana Labs
Wednesday, March 20 • 16:30 - 17:05 +- **[From RUM to Front-End Observability with OpenTelemetry](https://sched.co/1YeOH)**
+ by Purvi Kanal, Honeycomb
Thursday, March 21 • 11:00 - 11:35 +- **[Tutorial: Exploring the Power of Distributed Tracing with OpenTelemetry on Kubernetes](https://sched.co/1YePA)**
+ by Pavol Loffay & Benedikt Bongartz, Red Hat; Matej Gera, Coralogix; Anthony + Mirabella, AWS; Anusha Reddy Narapureddy, Apple
Thursday, March 21 • + 14:30 - 16:00 +- **[Prometheus and OpenTelemetry: Better Together](https://sched.co/1YePz)**
+ by Adriana Villela, ServiceNow Cloud Observability & Reese Lee, New Relic
+ Thursday, March 21 • 16:30 - 17:05 +- **[Observable Feature Rollouts with OpenTelemetry and OpenFeature](https://sched.co/1YeSC)**
+ by Daniel Dyla & Michael Beemer, Dynatrace
Friday, March 22 • 16:00 - + 16:35 + +## Observability Day + +_[Observability Day][] fosters collaboration, discussion, and knowledge sharing +of cloud-native observability projects_. This event will be held on March 19, +2024 from 9:00 - 17:35. There will be several sessions on OpenTelemetry as well: + +- **[Welcome + Project Updates](https://sched.co/1YGT9)**
by Eduardo Silva, + FluentBit & Austin Parker, honeycomb.io
Tuesday, March 19th • 09:00 - + 09:20 +- **[Dude, Where’s My Error?: How OpenTelemetry Records Errors, and Why It Does It Like That](https://sched.co/1YFeM)**
+ by Adriana Villela, ServiceNow Cloud Observability (formerly Lightstep) & + Reese Lee, New Relic
Tuesday, March 19th • 10:00 - 10:25 +- **[How to Think About Instrumentation Overhead](https://sched.co/1YFfb)**
+ by Jason Plumb, Splunk
Tuesday, March 19th • 11:05 - 11:30 +- **[TTChat’s Story: Connect Metrics, Logs and Traces with eBPF](https://sched.co/1YFfe)**
+ by Zhu Jiekun, Quwan
Tuesday, March 19th • 11:05 - 11:30 +- **[Panel: OpenTelemetry: Realizing the Value of Open Standards](https://sched.co/1YFgW)**
+ by Daniel Gomez Blanco, Skyscanner; Marcin Sodkiewicz, Ryanair; Iris Dyrmishi, + Miro; Hope Oluwalolope, Microsoft
Tuesday, March 19th • 12:15 - 12:50 +- **[Telemetry Showdown: Fluent Bit Vs. OpenTelemetry Collector - a Comprehensive Benchmark Analysis](https://sched.co/1YFhI)**
+ by Henrik Rexed, Dynatrace
Tuesday, March 19th • 13:30 - 13:55 +- **[Monitoring Serverless Workloads with OpenTelemetry and Prometheus](https://sched.co/1YFhh)**
+ by Ridwan Sharif, Google
Tuesday, March 19th • 14:05 - 14:30 +- **[Observability at the Edge: Instrumenting WebAssembly with OpenTelemetry](https://sched.co/1YFik)**
+ by Dan Norris & Joonas Bergius, Cosmonic
Tuesday, March 19th • 15:15 - + 15:40 +- **[Real-World Sampling – Lessons Learned After Reducing ~80% of Our O11y Costs](https://sched.co/1YFii)**
+ by Juraci Paixão Kröhling, Grafana Labs & Alexandre Magno Prado Machado, Pismo + Soluções Tecnológicas
Tuesday, March 19th • 15:15 - 15:40 +- **[⚡ Lightning Talk: Not Just Enterprise. Modern Java App CI/CD Observability with OTel, Quarkus and Gradle](https://sched.co/1YFin)**
+ by Oleg Nenashev, WireMock
Tuesday, March 19th • 15:45 - 15:50 +- **[Shift Into an Observability Mindset with OpenTelemetry](https://sched.co/1YFjB)**
+ by Daniel Gomez Blanco, Skyscanner
Tuesday, March 19th • 15:45 - 16:15 +- **[⚡ Lightning Talk: Federated Search Over Distributed Observability Data](https://sched.co/1YFjC)**
+ by Kalyan Kolachala, Intuit
Tuesday, March 19th • 15:55 - 16:00 +- **[⚡ Lightning Talk: Application Security Through the Lens of OpenTelemetry - Yosef Arbiv, Outshift by Cisco](https://sched.co/1YFf5)**
+ by Kalyan Kolachala, Intuit
Tuesday, March 19th • 16:05 - 16:10 +- **[Lazy Robots: Telemetry Buffering on Android](https://sched.co/1YFk3)**
+ by Cesar Munoz, Elastic & Jason Plumb, Splunk
Tuesday, March 19th • + 17:00 - 17:25 +- **[OpAMP in Action: User Configurable Observability Pipelines](https://sched.co/1YFk6)**
+ by Srikanth Chekuri, SigNoz
Tuesday, March 19th • 17:00 - 17:25 + +{{% alert title="Important access note" color="danger" %}} + +You need an _in-person all-access_ pass for on-site access to **Observability +Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, +you will be able to follow **Observability Day** through a live stream. + +[kubecon registration]: + https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/register/ + +{{% /alert %}} + +## OpenTelemetry Observatory + +Drop by and say _"Hi!"_ at OpenTelemetry Observatory presented by Splunk in the +Expo Hall. This will be a place for informal chats, meetups, and other +discussions led by OpenTelemetry community members and maintainers. Check out +the schedule of activities [here](https://shorturl.at/qEUX1). + +If you’d like to participate and lead a discussion or short presentation, out to +the +[OpenTelemetry End User Working Group](https://cloud-native.slack.com/archives/C01RT3MSWGZ) +to indicate your interest. + +You can help us improve the project by sharing your thoughts and feedback about +your OpenTelemetry adoption, implementation, and usage. + +To join a feedback session, book online below: + +- [End User Feedback Sessions 1](https://calendly.com/otel-euwg/end-user-feedback-sessions-1?month=2024-03) +- [End User Feedback Sessions 2](https://calendly.com/otel-euwg/end-user-feedback-sessions-2?month=2024-03) +- [End User Feedback Sessions 3](https://calendly.com/otel-euwg/end-user-feedback-sessions-3?month=2024-03) +- [End User Feedback Sessions 4](https://calendly.com/otel-euwg/end-user-feedback-sessions-4?month=2024-03) +- [End User Feedback Sessions 5](https://calendly.com/otel-euwg/end-user-feedback-sessions-5?month=2024-03) + +A maximum of 5 participants will join one SIG maintainer to provide feedback for +that SIG. Sessions will be recorded and posted on the +[OTel YouTube channel](https://youtube.com/@otel-official). The final SIG list +is still TBD, so check back here often! + +We will create action items from your comments as appropriate. Check +[#otel-user-research][] in CNCF's Slack instance for results and action item +updates to come after KubeCon EU. + +Back by popular demand! We'll be recording +[Humans of OTel interviews](/blog/2023/humans-of-otel/) at the OTel Observatory. +If you'd like to share your experiences as an OpenTelemetry practitioner or +maintainer, sign up for an interview session +[here](https://calendly.com/otel-euwg/humans-of-otel). + +Come join us to listen, learn, and get involved in OpenTelemetry. + +See you in Paris! + +[#otel-user-research]: https://cloud-native.slack.com/archives/C01RT3MSWGZ +[KubeCon + CloudNativeCon Europe]: + https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ +[Observability Day]: + https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/ diff --git a/content/en/blog/2024/otel-collector-anti-patterns/house-on-stilts.jpg b/content/en/blog/2024/otel-collector-anti-patterns/house-on-stilts.jpg new file mode 100644 index 000000000000..64ff14bccdb7 Binary files /dev/null and b/content/en/blog/2024/otel-collector-anti-patterns/house-on-stilts.jpg differ diff --git a/content/en/blog/2024/otel-collector-anti-patterns/index.md b/content/en/blog/2024/otel-collector-anti-patterns/index.md new file mode 100644 index 000000000000..17cf49cdca6a --- /dev/null +++ b/content/en/blog/2024/otel-collector-anti-patterns/index.md @@ -0,0 +1,185 @@ +--- +title: OpenTelemetry Collector Antipatterns +linkTitle: OTel Collector Antipatterns +date: 2024-03-01 +author: >- + [Adriana Villela](https://github.com/avillela) (Lightstep), + +canonical_url: https://open.substack.com/pub/geekingoutpodcast/p/opentelemetry-collector-anti-patterns +cSpell:ignore: antipattern antipatterns +--- + +![House on stilts against ocean and mountain backdrop](house-on-stilts.jpg) + +The [OpenTelemetry Collector](/docs/collector) is one of my favorite +OpenTelemetry (OTel) components. It’s a flexible and powerful data pipeline +which allows you to ingest OTel data from one or more sources, transform it +(including batching, filtering, and masking), and export it to one or more +observability backends for analysis. It’s vendor-neutral. It’s extensible, +meaning that you can create your own custom components for it. What’s there not +to like? + +Unfortunately, as it happens with many tools out there, it is also very easy to +fall into some bad habits. Today, I will dig into five OpenTelemetry Collector +antipatterns, and how to avoid them. Let’s get started! + +## Antipatterns + +### 1- Improper use of Collector deployment modes + +It’s not just enough to use a Collector. It’s also about _how_ your Collectors +are deployed within your organization. That’s right - Collector*s*, plural. +Because one is often not enough. + +There are two deployment modes for Collectors: agent mode and gateway mode, and +both are needed. + +In [agent mode](/docs/collector/deployment/agent/), the Collector sits next to +the application or on the same host as the application. + +![OTel Collector Agent Mode](otel-collector-agent.png) + +In [gateway mode](/docs/collector/deployment/gateway/), telemetry data is sent +to a load balancer, which then determines how to distribute the load amongst a +pool of Collectors. Because you have a pool of Collectors, should one Collector +in that pool fail, one of the other Collectors in the pool can take over. This +keeps data flowing to your destination sans disruptions. Gateway mode is +commonly deployed per cluster, data center, or region. + +![OTel Collector Agent Mode](otel-collector-gateway.png) + +So which should you use? Both agent and gateway. + +If you’re collecting telemetry data for your application, place a Collector +agent alongside your application. If you’re collecting data for infrastructure, +place a Collector agent alongside your infrastructure. Whatever you do, don’t +collect telemetry for all of your infrastructure and applications using a single +Collector. That way, if one Collector fails, the rest of your telemetry +collection is unaffected. + +The telemetry from your Collector agents can then be sent to a Collector +gateway. Because the gateway sits behind a load balancer, you don’t have a +single point of failure for exporting telemetry data, typically to your +observability backend. + +_Bottom line:_ Having the right Collector deployment configuration to send data +to your observability backend ensures higher availability of your telemetry +collection infrastructure. + +### 2- Not monitoring your Collectors + +Deploying multiple Collector agents and a Collector gateway is great, but it’s +not good enough. Wouldn’t it be nice to know when one of your Collectors is +malfunctioning, or when data is being dropped? That way, you can take action +before things start to escalate. This is where monitoring your Collectors can be +very useful. + +But how does one monitor a Collector? The OTel Collector already emits +[metrics for the purposes of its own monitoring](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/monitoring.md). +These can then be sent to your Observability backend for monitoring. + +### 3- Not using the right Collector Distribution (or not building your own distribution) + +There are two official distributions of the OpenTelemetry Collector: +[Core](https://github.com/open-telemetry/opentelemetry-collector), and +[Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib). + +The Core distribution is a bare-bones distribution of the Collector for OTel +developers to develop and test. It contains a base set of +[extensions](/docs/collector/configuration/#service-extensions), +[connectors](/docs/collector/configuration/#connectors), +[receivers](/docs/collector/configuration/#receivers), +[processors](/docs/collector/configuration/#processors), and +[exporters](/docs/collector/configuration/#exporters). + +The Contrib distribution is for non-OTel developers to experiment and learn. It +also extends the Core distribution, and includes components created by +third-parties (including vendors and individual community members), that are +useful to the OpenTelemetry community at large. + +Neither Core nor Contrib alone are meant to be part of your production workload. +Using just Core by itself is too bare-bones and wouldn’t suit an organization’s +needs. (Though its components are absolutely needed!) And although many +OpenTelemetry practitioners, deploy Contrib in their respective organizations, +it has many components, and you likely won’t need every single exporter, +receiver, processor, connector, and extension. That would be overkill, and your +Collector instance ends up needlessly bloated, potentially increasing the attack +surface. + +But how do you pick and choose the components that you need? The answer is to +build your own distribution, and you can do that using a tool called the +[OpenTelemetry Collector Builder](/docs/collector/custom-collector/) (OCB). In +addition, at some point, you may need to create your own custom Collector +component, such as a processor or exporter. The OCB allows you to integrate your +custom components AND pick and choose the Contrib components that you need. + +It is also worth mentioning that some vendors build their own +[Collector distributions](/ecosystem/distributions/). These are OTel Collector +distributions that are curated to Collector components that are specific to that +vendor. They may be a combination of custom, vendor-developed components, and +curated Collector Contrib components. Using vendor-specific distributions +ensures that you are using just the Collector components that you need, again +reducing overall bloat. + +_Bottom line:_ Using the right distribution reduces bloat and allows you to +include only the Collector components that you need. + +### 4- Not updating your Collectors + +This one’s short and sweet. Keeping software up-to-date is important, and the +Collector is no different! By regularly updating the Collector, it allows you to +stay up-to-date with the latest version so that you can take advantage of new +features, bug fixes, performance improvements, and security fixes. + +### 5- Not using the OpenTelemetry Collector where appropriate + +OpenTelemetry allows you to send telemetry signals from your application to an +observability backend in one of two ways: + +- [Directly from the application](/docs/collector/deployment/no-collector/) +- [Via the OpenTelemetry Collector](/docs/collector/) + +Sending telemetry data “direct from application” for non-production systems is +all well and good if you’re getting started with OpenTelemetry, but it is +neither suited nor recommended to use this approach for production systems. +Instead, the +[OpenTelemetry docs recommend using the OpenTelemetry Collector](/docs/collector/#when-to-use-a-collector). +How come? + +[Per the OTel Docs](/docs/collector/#when-to-use-a-collector), the Collector +“allows your service to offload data quickly and the collector can take care of +additional handling like retries, batching, encryption or even sensitive data +filtering.” + +Check out some additional Collector benefits: + +- **Collectors can enhance the quality of the telemetry emitted by an + application while also minimizing costs.** For example: sampling spans to + reduce costs, enriching telemetry with extra metadata, and generating new + telemetry, such as metrics derived from spans. +- **Using a Collector to ingest telemetry data makes it easy to change to a new + backend or export the data in a different format.** If we want to change how + telemetry is being processed or exported, that change happens in one place + (the Collector!), as opposed to making the same change for multiple + applications in your organization. +- **Collectors allow you to receive data of various formats and translate to the + desired format for export.** This can be very handy when transitioning from + some other telemetry solution to OTel. +- **Collectors allow you to ingest non-application telemetry.** This includes + logs and non-app metrics from infrastructure like Azure, Prometheus, and + Cloudwatch. + +That being said, there are some use-cases where folks don't want or can't use a +Collector. For instance, when collecting data at the edge from IOT devices, it +might be better to send data directly to their observability backend instead of +a local Collector, given that resources on that edge might be limited. + +_Bottom line:_ As a general rule, using the OpenTelemetry Collector gives you +additional flexibility for managing your telemetry data. + +## Final Thoughts + +The OpenTelemetry Collector is a powerful and flexible tool for ingesting, +manipulating, and exporting OpenTelemetry data. By using it to its full +potential and by avoiding these five pitfalls, your organization can be well on +its way towards achieving observability greatness. diff --git a/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-agent.png b/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-agent.png new file mode 100644 index 000000000000..a1af1423688c Binary files /dev/null and b/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-agent.png differ diff --git a/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-gateway.png b/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-gateway.png new file mode 100644 index 000000000000..b705bc5610a0 Binary files /dev/null and b/content/en/blog/2024/otel-collector-anti-patterns/otel-collector-gateway.png differ diff --git a/content/en/docs/concepts/components.md b/content/en/docs/concepts/components.md index 2feaa1efda67..bcdaade42ad5 100644 --- a/content/en/docs/concepts/components.md +++ b/content/en/docs/concepts/components.md @@ -12,7 +12,7 @@ OpenTelemetry is currently made up of several main components: - [Language-specific API \& SDK implementations](#language-specific-api--sdk-implementations) - [Instrumentation Libraries](#instrumentation-libraries) - [Exporters](#exporters) - - [Automatic Instrumentation](#automatic-instrumentation) + - [Zero-Code Instrumentation](#zero-code-instrumentation) - [Resource Detectors](#resource-detectors) - [Cross Service Propagators](#cross-service-propagators) - [Sampler](#sampler) @@ -75,7 +75,7 @@ For more information, see {{% docs/languages/exporters/intro %}} -### Automatic Instrumentation +### Zero-Code Instrumentation If applicable a language specific implementation of OpenTelemetry will provide a way to instrument your application without touching your source code. While the @@ -84,7 +84,7 @@ OpenTelemetry API and SDK capabilities to your application. Additionally they may add a set of Instrumentation Libraries and exporter dependencies. For more information, see -[Instrumenting](/docs/concepts/instrumentation/automatic/). +[Zero-Code Instrumentation](/docs/concepts/instrumentation/zero-code/). ### Resource Detectors diff --git a/content/en/docs/concepts/instrumentation/_index.md b/content/en/docs/concepts/instrumentation/_index.md index 1b897cb8c7b9..cb11487a2902 100644 --- a/content/en/docs/concepts/instrumentation/_index.md +++ b/content/en/docs/concepts/instrumentation/_index.md @@ -1,8 +1,7 @@ --- title: Instrumentation description: >- - How OpenTelemetry facilitates automatic and manual instrumentation of - applications. + How OpenTelemetry instrumentations libraries and applications. aliases: [instrumenting] weight: 15 --- @@ -12,32 +11,48 @@ from the system's components must emit [traces](/docs/concepts/signals/traces/), [metrics](/docs/concepts/signals/metrics/), and [logs](/docs/concepts/signals/logs/). -Without being required to modify the source code you can collect telemetry from -an application using [automatic instrumentation](automatic/). If you previously -used an APM agent to extract telemetry from your application, Automatic -Instrumentation will give you a similar out of the box experience. - -To facilitate the instrumentation of applications even more, you can -[manually instrument](manual/) your applications by coding against the -OpenTelemetry APIs. - -For that you don't need to instrument all the dependencies used in your -application: - -- some of your libraries will be observable out of the box by calling the - OpenTelemetry API themselves directly. Those libraries are sometimes called - **natively instrumented**. -- for libraries without such an integration the OpenTelemetry projects provide - language specific [Instrumentation Libraries][] - -Note, that for most languages it is possible to use both manual and automatic -instrumentation at the same time: Automatic Instrumentation will allow you to -gain insights into your application quickly and manual instrumentation will -enable you to embed granular observability into your code. - -The exact installation mechanism for [manual](manual/) and -[automatic](automatic/) instrumentation varies based on the language you’re -developing in, but there are some similarities covered in the sections below. - -[instrumentation libraries]: - /docs/specs/otel/overview/#instrumentation-libraries +OpenTelemetry has two primary ways to instrument. + +1. [Code-based solutions](/docs/concepts/instrumentation/code-based) via + official APIs and SDKs for eleven languages. +2. [Zero-code solutions](/docs/concepts/instrumentation/zero-code/) that, when + installed, instrument libraries you use. + +Code-based solutions allow you to get rich telemetry from your application +itself. They let you use the OpenTelemetry API to generate telemetry from your +application, which acts as an essential complement to the telemetry generated by +zero-code solutions. + +The Zero-code solutions are great for getting started, or when you can't modify +the application you need to get telemetry out of. They provide rich telemetry +from libraries you use and/or the environment your application runs in. Another +way to think of it is that they provide information about what's happening _at +the edges_ of your application. + +It's generally recommended that you use both solutions when you can. + +## Additional OpenTelemetry Benefits + +OpenTelemetry provides more than just zero-code and code-based telemetry +solutions. The following things are also a part of OpenTelemetry: + +- Libraries can leverage the OpenTelemetry API as a dependency, which will have + no impact on applications using that library, unless the OpenTelemetry SDK is + imported. +- For each [signal](/docs/concepts/signals) (traces, metrics, logs) you have + several methods at your disposals to create, process, and export them. +- With [context propagation](/docs/concepts/context-propagation) built into the + implementations, you can correlate signals regardless of where they are + generated. +- [Resources](/docs/concepts/resources) and + [Instrumentation Scopes](/docs/concepts/instrumentation-scope) allow grouping + of signals, by different entities, like, the + [host](/docs/specs/semconv/resource/host/), + [operating system](/docs/specs/semconv/resource/os/) or + [K8s cluster](/docs/specs/semconv/resource/k8s/#cluster) +- Each language-specific implementation of the API and SDK follows the + requirements and expectations of the + [OpenTelemetry specification](/docs/specs/otel/). +- [Semantic Conventions](/docs/concepts/semantic-conventions) provide a common + naming schema that can be used for standardization across code bases and + platforms. diff --git a/content/en/docs/concepts/instrumentation/automatic.md b/content/en/docs/concepts/instrumentation/automatic.md deleted file mode 100644 index e73c94fd336b..000000000000 --- a/content/en/docs/concepts/instrumentation/automatic.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Automatic -description: >- - Learn how Automatic Instrumentation can add observability to your application - without the need to touch your code -weight: 10 ---- - -If applicable a language specific implementation of OpenTelemetry will provide a -way to instrument your application without touching your source code. While the -underlying mechanism depends on the language, at a minimum this will add the -OpenTelemetry API and SDK capabilities to your application. Additionally they -may add a set of Instrumentation Libraries and exporter dependencies. - -Configuration is available via environment variables and possibly language -specific means such as system properties in Java. At a minimum, a service name -must be configured to identify the service being instrumented. A variety of -other configuration options are available and may include: - -- Data source specific configuration -- Exporter configuration -- Propagator configuration -- Resource configuration - -Automatic instrumentation is available for the following languages: - -- [.NET](/docs/languages/net/automatic/) -- [Java](/docs/languages/java/automatic/) -- [JavaScript](/docs/languages/js/automatic/) -- [PHP](/docs/languages/php/automatic/) -- [Python](/docs/languages/python/automatic/) diff --git a/content/en/docs/concepts/instrumentation/manual.md b/content/en/docs/concepts/instrumentation/code-based.md similarity index 96% rename from content/en/docs/concepts/instrumentation/manual.md rename to content/en/docs/concepts/instrumentation/code-based.md index e46f0767e15b..3a669088f781 100644 --- a/content/en/docs/concepts/instrumentation/manual.md +++ b/content/en/docs/concepts/instrumentation/code-based.md @@ -1,8 +1,9 @@ --- -title: Manual +title: Code-based description: >- - Learn about the essential steps to manually instrument your application. + Learn about the essential steps to instrument your code base. weight: 20 +aliases: [manual] cSpell:ignore: legitimatebusiness proxying --- diff --git a/content/en/docs/concepts/instrumentation/zero-code.md b/content/en/docs/concepts/instrumentation/zero-code.md new file mode 100644 index 000000000000..ca8787f06295 --- /dev/null +++ b/content/en/docs/concepts/instrumentation/zero-code.md @@ -0,0 +1,51 @@ +--- +title: Zero-code +description: >- + Learn how to add observability to an application without the need to write + more code +weight: 10 +aliases: [automatic] +--- + +As [ops](/docs/getting-started/ops/) you might want to add observability to one +or more applications without having to edit the source. OpenTelemetry lets you +quickly gain some observability for a service without having to use the +OpenTelemetry API & SDK for +[code-based instrumentation](/docs/concepts/instrumentation/code-based). + +Zero-code instrumentation adds the OpenTelemetry API and SDK capabilities to +your application typically as an agent or agent-like installation. The specific +mechanisms involved may differ by language, ranging from bytecode manipulation, +monkey patching, or eBPF to inject calls to the OpenTelemetry API and SDK into +your application. + +Typically, zero-code instrumentation adds instrumentation for the libraries +you're using. This means that requests and responses, database calls, message +queue calls, and so forth are what are instrumented. Your application's code, +however, is not typically instrumented. To instrument your code, you'll need to +use [code-based instrumentation](/docs/concepts/instrumentation/code-based). + +Additionally, zero-code instrumentation lets you configure the +[Instrumentation Libraries](/docs/concepts/instrumentation/libraries) and +[exporters](/docs/concepts/components/#exporters) loaded. + +You can configure zero-code instrumentation through environment variables and +other language-specific mechanisms, such as system properties or arguments +passed to initialization methods. To get started, you only need a service name +configured so that you can identify the service in the observability backend of +your choice. + +Other configuration options are available, including: + +- Data source specific configuration +- Exporter configuration +- Propagator configuration +- Resource configuration + +Automatic instrumentation is available for the following languages: + +- [.NET](/docs/languages/net/automatic/) +- [Java](/docs/languages/java/automatic/) +- [JavaScript](/docs/languages/js/automatic/) +- [PHP](/docs/languages/php/automatic/) +- [Python](/docs/languages/python/automatic/) diff --git a/content/en/docs/demo/services/cart.md b/content/en/docs/demo/services/cart.md index 862acbe704ae..d325d9d6f74e 100644 --- a/content/en/docs/demo/services/cart.md +++ b/content/en/docs/demo/services/cart.md @@ -25,7 +25,8 @@ and resource attributes is performed through environment variables. ```cs Action appResourceBuilder = resource => resource - .AddDetector(new ContainerResourceDetector()); + .AddDetector(new ContainerResourceDetector()) + .AddDetector(new HostDetector()); builder.Services.AddOpenTelemetry() .ConfigureResource(appResourceBuilder) diff --git a/content/en/docs/demo/telemetry-features/metric-coverage.md b/content/en/docs/demo/telemetry-features/metric-coverage.md index 5cdf35be0bf8..67d6d1d662b6 100644 --- a/content/en/docs/demo/telemetry-features/metric-coverage.md +++ b/content/en/docs/demo/telemetry-features/metric-coverage.md @@ -4,22 +4,22 @@ linkTitle: Metric Coverage aliases: [metric_service_features, metric-features, ../metric-features] --- -| Service | Language | Auto-instrumentation | Manual Instrumentation | Multiple Instruments | Views | Custom Attributes | Resource Detection | Trace Exemplars | -| --------------- | --------------- | -------------------- | ---------------------- | -------------------- | ----- | ----------------- | ------------------ | --------------- | -| Accounting | Go | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Ad | Java | ✅ | ✅ | 🚧 | 🚧 | ✅ | ✅ | ✅ | -| Cart | .NET | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Checkout | Go | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Currency | C++ | 🔕 | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Email | Ruby | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Feature Flag | Erlang / Elixir | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Fraud Detection | Kotlin | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | ✅ | 🚧 | -| Frontend | TypeScript | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Payment | JavaScript | 🚧 | ✅ | 🚧 | 🚧 | 🚧 | ✅ | 🚧 | -| Product Catalog | Go | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Quote | PHP | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Recommendation | Python | ✅ | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | -| Shipping | Rust | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Service | Language | Instrumentation Libraries | Manual Instrumentation | Multiple Instruments | Views | Custom Attributes | Resource Detection | Exemplars | +| --------------- | --------------- | ------------------------- | ---------------------- | -------------------- | ----- | ----------------- | ------------------ | --------- | +| Accounting | Go | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Ad | Java | ✅ | ✅ | 🚧 | 🚧 | ✅ | ✅ | ✅ | +| Cart | .NET | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Checkout | Go | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Currency | C++ | 🔕 | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Email | Ruby | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Feature Flag | Erlang / Elixir | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Fraud Detection | Kotlin | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | ✅ | 🚧 | +| Frontend | TypeScript | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Payment | JavaScript | 🚧 | ✅ | 🚧 | 🚧 | 🚧 | ✅ | 🚧 | +| Product Catalog | Go | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Quote | PHP | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Recommendation | Python | ✅ | ✅ | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | +| Shipping | Rust | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | 🚧 | Emoji Legend: diff --git a/content/en/docs/getting-started/dev.md b/content/en/docs/getting-started/dev.md index 21ddfbe2f2b7..63063e4f9a96 100644 --- a/content/en/docs/getting-started/dev.md +++ b/content/en/docs/getting-started/dev.md @@ -14,8 +14,7 @@ instrumented automatically and instrumenting your own code with our API manually, we recommend that you learn the following concepts first: - [What is OpenTelemetry?](/docs/what-is-opentelemetry/) -- [How can I instrument dependencies without touching their code?](/docs/concepts/instrumentation/automatic/) -- [How can I instrument my application manually?](/docs/concepts/instrumentation/manual/) +- [How can I add instrumentation to my code base?](/docs/concepts/instrumentation/code-based/) If you develop libraries, frameworks or middleware that is used as a dependency within other software, we recommend that you learn how you can provide telemetry diff --git a/content/en/docs/getting-started/ops.md b/content/en/docs/getting-started/ops.md index e9a193ef563c..24a16a0d0980 100644 --- a/content/en/docs/getting-started/ops.md +++ b/content/en/docs/getting-started/ops.md @@ -15,7 +15,7 @@ applications without touching their code, we recommend that you learn the following: - [What is OpenTelemetry?](/docs/what-is-opentelemetry/) -- [How can I instrument applications without touching their code?](/docs/concepts/instrumentation/automatic/) +- [How can I instrument applications without touching their code?](/docs/concepts/instrumentation/zero-code/) - [How can I set up a collector?](/docs/collector/) - [How can I get automation for Kubernetes with the OpenTelemetry Operator?](/docs/kubernetes/operator/) diff --git a/content/en/docs/kubernetes/operator/automatic.md b/content/en/docs/kubernetes/operator/automatic.md index e2f956661ebd..413b39d57785 100644 --- a/content/en/docs/kubernetes/operator/automatic.md +++ b/content/en/docs/kubernetes/operator/automatic.md @@ -318,8 +318,7 @@ EOF ``` > **Note**: OpenTelemetry Python automatic instrumentation does not support -> Flask or Werkzeug 3.0+ at this time. See the troubleshooting section -> [No Data When Using Flask](/docs/languages/python/automatic#no-data-when-using-flask) +> Flask or Werkzeug 3.0+ at this time. By default, the `Instrumentation` resource that auto-instruments Python services uses `otlp` with the `http/protobuf` protocol (gRPC is not supported at this diff --git a/content/en/docs/languages/js/instrumentation.md b/content/en/docs/languages/js/instrumentation.md index a7362827294b..ce15570ae37b 100644 --- a/content/en/docs/languages/js/instrumentation.md +++ b/content/en/docs/languages/js/instrumentation.md @@ -1261,10 +1261,9 @@ const metricReader = new PeriodicExportingMetricReader({ const myServiceMeterProvider = new MeterProvider({ resource: resource, + readers: [metricReader], }); -myServiceMeterProvider.addMetricReader(metricReader); - // Set this MeterProvider to be global to the app being instrumented. opentelemetry.metrics.setGlobalMeterProvider(myServiceMeterProvider); ``` @@ -1299,10 +1298,9 @@ const metricReader = new PeriodicExportingMetricReader({ const myServiceMeterProvider = new MeterProvider({ resource: resource, + readers: [metricReader], }); -myServiceMeterProvider.addMetricReader(metricReader); - // Set this MeterProvider to be global to the app being instrumented. opentelemetry.metrics.setGlobalMeterProvider(myServiceMeterProvider); ``` diff --git a/content/en/docs/languages/python/automatic/_index.md b/content/en/docs/languages/python/automatic/_index.md index d07228ad5486..3e24342ab725 100644 --- a/content/en/docs/languages/python/automatic/_index.md +++ b/content/en/docs/languages/python/automatic/_index.md @@ -75,19 +75,6 @@ You can find the full list ## Troubleshooting -### No data when using Flask - -Using OpenTelemetry with Flask requires both Flask and Werkzeug versions as < -3.0. Because Flask 2.x does not specify Werkzeug as < 3.0, conflicts can arise. - -Ensure your Flask version is < 3.x, and specify the Werkzeug version explicitly -as < 3.0. For example, in a `pyproject.toml` file: - -```console -flask = "2.2.2" -Werkzeug = "2.2.2" -``` - ### Python package installation failure The Python package installs require `gcc` and `gcc-c++`, which you may need to diff --git a/content/en/docs/languages/python/automatic/example.md b/content/en/docs/languages/python/automatic/example.md index bdd3c8eceadd..2b66f9417ed6 100644 --- a/content/en/docs/languages/python/automatic/example.md +++ b/content/en/docs/languages/python/automatic/example.md @@ -101,13 +101,9 @@ which provides several commands that help automatically instrument a program. ```sh pip install opentelemetry-distro -pip install 'flask<3' 'werkzeug<3' requests +pip install flask requests ``` -> **Note**: OpenTelemetry Python automatic instrumentation does not support -> Flask or Werkzeug 3.0+ at this time. See the troubleshooting section -> [No Data When Using Flask](/docs/languages/python/automatic#no-data-when-using-flask) - Run the `opentelemetry-bootstrap` command: ```shell diff --git a/content/en/docs/languages/python/getting-started.md b/content/en/docs/languages/python/getting-started.md index 5030bfa94583..1fd4e6917c8a 100644 --- a/content/en/docs/languages/python/getting-started.md +++ b/content/en/docs/languages/python/getting-started.md @@ -39,16 +39,12 @@ python3 -m venv venv source ./venv/bin/activate ``` -Now install Flask and Werkzeug: +Now install Flask: ```shell -pip install 'flask<3' 'werkzeug<3' +pip install flask ``` -> **Note**: OpenTelemetry Python automatic instrumentation does not support -> Flask or Werkzeug 3.0+ at this time. See the troubleshooting section -> [No Data When Using Flask](/docs/languages/python/automatic#no-data-when-using-flask) - ### Create and launch an HTTP Server Create a file `app.py` and add the following code to it: diff --git a/data/registry/exporter-js-instana.yml b/data/registry/exporter-js-instana.yml index 13316c57bc33..d93e340ecefa 100644 --- a/data/registry/exporter-js-instana.yml +++ b/data/registry/exporter-js-instana.yml @@ -15,4 +15,4 @@ createdAt: 2022-04-18 package: registry: npm name: '@instana/opentelemetry-exporter' - version: 3.1.3 + version: 3.2.0 diff --git a/data/registry/exporter-js-jaeger.yml b/data/registry/exporter-js-jaeger.yml index 3f4613b26d19..4b99c5a9cb30 100644 --- a/data/registry/exporter-js-jaeger.yml +++ b/data/registry/exporter-js-jaeger.yml @@ -14,4 +14,4 @@ createdAt: 2020-02-06 package: registry: npm name: '@opentelemetry/exporter-jaeger' - version: 1.21.0 + version: 1.22.0 diff --git a/data/registry/exporter-js-prometheus.yml b/data/registry/exporter-js-prometheus.yml index 16baac5c1d96..41c5f5185e48 100644 --- a/data/registry/exporter-js-prometheus.yml +++ b/data/registry/exporter-js-prometheus.yml @@ -14,4 +14,4 @@ createdAt: 2020-02-06 package: registry: npm name: '@opentelemetry/exporter-prometheus' - version: 0.48.0 + version: 0.49.1 diff --git a/data/registry/exporter-js-zipkin.yml b/data/registry/exporter-js-zipkin.yml index f6ae908d04d1..2d7df21238f8 100644 --- a/data/registry/exporter-js-zipkin.yml +++ b/data/registry/exporter-js-zipkin.yml @@ -11,7 +11,7 @@ authors: package: name: '@opentelemetry/exporter-zipkin' registry: npm - version: 1.21.0 + version: 1.22.0 urls: repo: https://github.com/open-telemetry/opentelemetry-js/tree/main/packages/opentelemetry-exporter-zipkin docs: /docs/languages/js/exporters/#zipkin diff --git a/data/registry/exporter-php-otlp.yml b/data/registry/exporter-php-otlp.yml index 2ff256cd3efb..54d7518159c1 100644 --- a/data/registry/exporter-php-otlp.yml +++ b/data/registry/exporter-php-otlp.yml @@ -14,7 +14,7 @@ authors: package: registry: packagist name: open-telemetry/exporter-otlp - version: '1.0.3' + version: '1.0.4' urls: repo: https://github.com/open-telemetry/opentelemetry-php/tree/main/src/Contrib/Otlp createdAt: 2022-12-14 diff --git a/data/registry/exporter-rust-datadog.yml b/data/registry/exporter-rust-datadog.yml new file mode 100644 index 000000000000..39890cf5a19d --- /dev/null +++ b/data/registry/exporter-rust-datadog.yml @@ -0,0 +1,19 @@ +# cSpell:ignore Datadog +title: Datadog Exporter +registryType: exporter +language: rust +tags: + - rust + - exporter + - propagators +license: Apache 2.0 +description: A Rust OpenTelemetry exporter and propagators for Datadog +authors: + - name: OpenTelemetry Authors +urls: + repo: https://github.com/open-telemetry/opentelemetry-rust-contrib/tree/main/opentelemetry-datadog +createdAt: 2021-03-24 +package: + registry: crates + name: opentelemetry-datadog + version: 0.10.0 diff --git a/data/registry/exporter-rust-stackdriver.yml b/data/registry/exporter-rust-stackdriver.yml index 311b3fce40fd..09480cab58bd 100644 --- a/data/registry/exporter-rust-stackdriver.yml +++ b/data/registry/exporter-rust-stackdriver.yml @@ -1,5 +1,5 @@ # cSpell:ignore jacobkiesel stackdriver -title: Google StackDrive Exporter +title: Google StackDriver Exporter registryType: exporter language: rust tags: @@ -9,8 +9,9 @@ license: Apache 2.0 OR MIT description: A Rust OpenTelemetry exporter for Google StackDriver authors: - name: jacobkiesel + - name: OpenTelemetry Authors urls: - repo: https://github.com/vivint-smarthome/opentelemetry-stackdriver + repo: https://github.com/open-telemetry/opentelemetry-rust-contrib/tree/main/opentelemetry-stackdriver createdAt: 2020-08-28 package: registry: crates diff --git a/data/registry/exporter-rust-user-events-logs.yml b/data/registry/exporter-rust-user-events-logs.yml new file mode 100644 index 000000000000..52fe0da2cd74 --- /dev/null +++ b/data/registry/exporter-rust-user-events-logs.yml @@ -0,0 +1,21 @@ +title: user_events Logs Exporter +registryType: exporter +language: rust +tags: + - rust + - exporter + - linux + - user_events +license: Apache 2.0 OR MIT +description: + A Rust OpenTelemetry Log exporter for [Linux Kernel + user_events](https://docs.kernel.org/trace/user_events.html) +authors: + - name: OpenTelemetry Authors +urls: + repo: https://github.com/open-telemetry/opentelemetry-rust-contrib/tree/main/opentelemetry-user-events-logs +createdAt: 2023-07-29 +package: + registry: crates + name: opentelemetry-user-events-logs + version: 0.3.0 diff --git a/data/registry/exporter-rust-user-events-metrics.yml b/data/registry/exporter-rust-user-events-metrics.yml new file mode 100644 index 000000000000..593a5a240008 --- /dev/null +++ b/data/registry/exporter-rust-user-events-metrics.yml @@ -0,0 +1,21 @@ +title: user_events Metrics Exporter +registryType: exporter +language: rust +tags: + - rust + - exporter + - linux + - user_events +license: Apache 2.0 OR MIT +description: + A Rust OpenTelemetry Metric exporter for [Linux Kernel + user_events](https://docs.kernel.org/trace/user_events.html) +authors: + - name: OpenTelemetry Authors +urls: + repo: https://github.com/open-telemetry/opentelemetry-rust-contrib/tree/main/opentelemetry-user-events-metrics +createdAt: 2023-07-29 +package: + registry: crates + name: opentelemetry-user-events-metrics + version: 0.3.0 diff --git a/data/registry/instrumentation-dotnet-kafkaflow.yml b/data/registry/instrumentation-dotnet-kafkaflow.yml index 4e4b1c3e5314..85994f8d0bb2 100644 --- a/data/registry/instrumentation-dotnet-kafkaflow.yml +++ b/data/registry/instrumentation-dotnet-kafkaflow.yml @@ -20,4 +20,4 @@ isFirstParty: true package: name: KafkaFlow.OpenTelemetry registry: nuget - version: 3.0.3 + version: 3.0.4 diff --git a/data/registry/instrumentation-erlang-req.yml b/data/registry/instrumentation-erlang-req.yml index 9d92640c4e5c..e12fdeac835a 100644 --- a/data/registry/instrumentation-erlang-req.yml +++ b/data/registry/instrumentation-erlang-req.yml @@ -6,8 +6,7 @@ tags: - instrumentation - erlang license: Apache 2.0 -description: - See https://hex.pm/packages/opentelemetry_req for usage instructions. +description: For details, see . authors: - name: OpenTelemetry Authors urls: diff --git a/data/registry/instrumentation-go-mongodb.yml b/data/registry/instrumentation-go-mongodb.yml index 68c178380b18..cb3551a40fbc 100644 --- a/data/registry/instrumentation-go-mongodb.yml +++ b/data/registry/instrumentation-go-mongodb.yml @@ -9,7 +9,7 @@ tags: license: Apache 2.0 description: Package mongo-driver provides functions to trace the - go.mongodb.org/mongo-driver/mongo(https://github.com/mongodb/mongo-go-driver) + [go.mongodb.org/mongo-driver/mongo](https://github.com/mongodb/mongo-go-driver) package. authors: - name: OpenTelemetry Authors diff --git a/data/registry/instrumentation-go-xsam-database-sql.yml b/data/registry/instrumentation-go-xsam-database-sql.yml index 22a189237f49..0cdf89d12705 100644 --- a/data/registry/instrumentation-go-xsam-database-sql.yml +++ b/data/registry/instrumentation-go-xsam-database-sql.yml @@ -15,7 +15,7 @@ authors: package: name: github.com/XSAM/otelsql registry: go - version: v0.28.0 + version: v0.29.0 urls: repo: https://github.com/XSAM/otelsql createdAt: 2021-10-12 diff --git a/data/registry/instrumentation-js-cerbos.yml b/data/registry/instrumentation-js-cerbos.yml index b2ad1139055b..e3f1edf431bf 100644 --- a/data/registry/instrumentation-js-cerbos.yml +++ b/data/registry/instrumentation-js-cerbos.yml @@ -18,5 +18,5 @@ createdAt: 2023-09-13 package: name: '@cerbos/opentelemetry' registry: npm - version: 0.4.2 + version: 0.4.3 isFirstParty: true diff --git a/data/registry/instrumentation-js-fetch.yml b/data/registry/instrumentation-js-fetch.yml index a0db0a273f35..aa447736383c 100644 --- a/data/registry/instrumentation-js-fetch.yml +++ b/data/registry/instrumentation-js-fetch.yml @@ -14,4 +14,4 @@ createdAt: 2020-11-09 package: registry: npm name: '@opentelemetry/instrumentation-fetch' - version: 0.48.0 + version: 0.49.1 diff --git a/data/registry/instrumentation-js-grpc.yml b/data/registry/instrumentation-js-grpc.yml index 016650a04613..fdbeb93df87a 100644 --- a/data/registry/instrumentation-js-grpc.yml +++ b/data/registry/instrumentation-js-grpc.yml @@ -14,4 +14,4 @@ createdAt: 2020-11-09 package: registry: npm name: '@opentelemetry/instrumentation-grpc' - version: 0.48.0 + version: 0.49.1 diff --git a/data/registry/instrumentation-js-http.yml b/data/registry/instrumentation-js-http.yml index 20baedf377fb..fe895fa9002f 100644 --- a/data/registry/instrumentation-js-http.yml +++ b/data/registry/instrumentation-js-http.yml @@ -14,4 +14,4 @@ createdAt: 2020-11-09 package: registry: npm name: '@opentelemetry/instrumentation-http' - version: 0.48.0 + version: 0.49.1 diff --git a/data/registry/instrumentation-js-xml-http-request.yml b/data/registry/instrumentation-js-xml-http-request.yml index a46237ed5fea..525d1d5ba4b0 100644 --- a/data/registry/instrumentation-js-xml-http-request.yml +++ b/data/registry/instrumentation-js-xml-http-request.yml @@ -14,4 +14,4 @@ createdAt: 2020-11-09 package: registry: npm name: '@opentelemetry/instrumentation-xml-http-request' - version: 0.48.0 + version: 0.49.1 diff --git a/data/registry/instrumentation-php-guzzle.yml b/data/registry/instrumentation-php-guzzle.yml index d94b398b6aba..125de5674dad 100644 --- a/data/registry/instrumentation-php-guzzle.yml +++ b/data/registry/instrumentation-php-guzzle.yml @@ -15,4 +15,4 @@ createdAt: 2024-01-19 package: registry: packagist name: open-telemetry/opentelemetry-auto-guzzle - version: 0.0.1 + version: 0.0.2 diff --git a/data/registry/instrumentation-php-httpasyncclient.yml b/data/registry/instrumentation-php-httpasyncclient.yml index d5f213bf70a3..aff65641b336 100644 --- a/data/registry/instrumentation-php-httpasyncclient.yml +++ b/data/registry/instrumentation-php-httpasyncclient.yml @@ -16,4 +16,4 @@ createdAt: 2023-05-22 package: registry: packagist name: open-telemetry/opentelemetry-auto-http-async - version: 1.0.0beta4 + version: 1.0.0beta5 diff --git a/data/registry/instrumentation-php-laravel.yml b/data/registry/instrumentation-php-laravel.yml index c55e08f56a52..ead5cfb5f858 100644 --- a/data/registry/instrumentation-php-laravel.yml +++ b/data/registry/instrumentation-php-laravel.yml @@ -15,4 +15,4 @@ createdAt: 2023-05-22 package: registry: packagist name: open-telemetry/opentelemetry-auto-laravel - version: 0.0.22 + version: 0.0.23 diff --git a/data/registry/instrumentation-php-psr14.yml b/data/registry/instrumentation-php-psr14.yml index 45b66970bea2..5d739d82401b 100644 --- a/data/registry/instrumentation-php-psr14.yml +++ b/data/registry/instrumentation-php-psr14.yml @@ -10,7 +10,7 @@ urls: license: Apache 2.0 description: This is a read-only subtree split of - https://github.com/open-telemetry/opentelemetry-php-contrib. + . authors: - name: OpenTelemetry Authors createdAt: 2024-01-19 diff --git a/data/registry/instrumentation-php-symfony.yml b/data/registry/instrumentation-php-symfony.yml index 976b53459f19..32840a04dac3 100644 --- a/data/registry/instrumentation-php-symfony.yml +++ b/data/registry/instrumentation-php-symfony.yml @@ -15,4 +15,4 @@ createdAt: 2023-05-22 package: registry: packagist name: open-telemetry/opentelemetry-auto-symfony - version: 1.0.0beta22 + version: 1.0.0beta23 diff --git a/data/registry/instrumentation-rust-trillium.yml b/data/registry/instrumentation-rust-trillium.yml new file mode 100644 index 000000000000..cf4c1b830979 --- /dev/null +++ b/data/registry/instrumentation-rust-trillium.yml @@ -0,0 +1,18 @@ +# cSpell:ignore Rothstein +title: Trillium Instrumentation +registryType: instrumentation +language: rust +tags: + - rust + - instrumentation +license: Apache 2.0 OR MIT +description: OpenTelemetry integration for the Trillium web framework. +authors: + - name: Jacob Rothstein +urls: + repo: https://github.com/trillium-rs/trillium-opentelemetry +createdAt: 2021-04-25 +package: + registry: crates + name: opentelemetry-trillium-opentelemetry + version: 0.2.16 diff --git a/data/registry/tools-go-propagator-datadog.yml b/data/registry/tools-go-propagator-datadog.yml index 78ce8e11bae8..dbef6bad684e 100644 --- a/data/registry/tools-go-propagator-datadog.yml +++ b/data/registry/tools-go-propagator-datadog.yml @@ -9,8 +9,7 @@ tags: license: Apache 2.0 description: > This library provides support for propagating trace context in the Datadog - X-Datadog-* format. - + `X-Datadog-*` format. authors: - name: Tony Li url: https://github.com/tonglil diff --git a/data/registry/tools-php-propagator-b3.yml b/data/registry/tools-php-propagator-b3.yml index 573df014680a..a16c4848617d 100644 --- a/data/registry/tools-php-propagator-b3.yml +++ b/data/registry/tools-php-propagator-b3.yml @@ -9,7 +9,6 @@ tags: license: Apache 2.0 description: > This library provides support for propagating trace context in the B3 format. - authors: - name: OpenTelemetry Authors urls: diff --git a/data/registry/tools-python-propagator-gcp.yml b/data/registry/tools-python-propagator-gcp.yml index 2df310b43a91..b4e6a13309aa 100644 --- a/data/registry/tools-python-propagator-gcp.yml +++ b/data/registry/tools-python-propagator-gcp.yml @@ -10,8 +10,7 @@ tags: license: Apache 2.0 description: > This library provides support for propagating trace context in the Google - Cloud X-Cloud-Trace-Context format. - + Cloud `X-Cloud-Trace-Context` format. authors: - name: Google urls: diff --git a/data/registry/tools-rust-aws.yml b/data/registry/tools-rust-aws.yml new file mode 100644 index 000000000000..85896238a5c7 --- /dev/null +++ b/data/registry/tools-rust-aws.yml @@ -0,0 +1,21 @@ +title: AWS Utilities +registryType: utilities +description: Utilities related to AWS including XRay Propagator and IDGenerator. +language: rust +tags: + - rust + - utilities + - propagator + - aws + - xray +license: Apache 2.0 +authors: + - name: OpenTelemetry Authors + +urls: + repo: https://github.com/open-telemetry/opentelemetry-rust-contrib/tree/main/opentelemetry-aws +createdAt: 2021-02-08 +package: + registry: crates + name: opentelemetry-aws + version: 0.10.0 diff --git a/data/registry/tools-rust-propagator-jaeger.yml b/data/registry/tools-rust-propagator-jaeger.yml new file mode 100644 index 000000000000..8f72423afaba --- /dev/null +++ b/data/registry/tools-rust-propagator-jaeger.yml @@ -0,0 +1,21 @@ +title: OpenTelemetry Jaeger context propagation +registryType: utilities +language: rust +tags: + - rust + - jaeger + - utilities + - propagator +license: Apache 2.0 +description: > + This library provides support for propagating trace context in the [Jaeger + format](https://www.jaegertracing.io/docs/1.20/client-libraries/#propagation-format). +authors: + - name: OpenTelemetry Authors +urls: + repo: https://github.com/open-telemetry/opentelemetry-rust/tree/main/opentelemetry-jaeger-propagator +createdAt: 2024-02-25 +package: + registry: crates + name: opentelemetry-jaeger-propagator + version: 0.1.0 diff --git a/hugo.yaml b/hugo.yaml index ae6fce296923..e12e049dd3d2 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -22,6 +22,8 @@ imaging: markup: goldmark: + extensions: + linkify: false parser: attribute: block: true diff --git a/layouts/partials/banner.md b/layouts/partials/banner.md index 530144ff89e1..c7efd45c92ef 100644 --- a/layouts/partials/banner.md +++ b/layouts/partials/banner.md @@ -3,7 +3,8 @@
-[Thanks to all the wonderful humans who have contributed to OpenTelemetry to date. We look forward to your contributions in 2024!](/blog/2023/humans-of-otel/) + Join us at +[**KubeCon + CloudNativeCon EU**, March 19 - 22, 2024](/blog/2024/kubecon-eu/)! {{/* diff --git a/static/refcache.json b/static/refcache.json index ff6cacc20297..0297bea18a7b 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -39,6 +39,10 @@ "StatusCode": 200, "LastSeen": "2024-01-18T08:05:55.59597-05:00" }, + "https://adri-v.medium.com/43dca4a857a0": { + "StatusCode": 200, + "LastSeen": "2024-02-23T23:30:53.006527-05:00" + }, "https://agilecoffee.com/leancoffee/": { "StatusCode": 200, "LastSeen": "2024-01-18T08:05:43.542109-05:00" @@ -191,6 +195,30 @@ "StatusCode": 206, "LastSeen": "2024-01-30T06:01:19.540115-05:00" }, + "https://calendly.com/otel-euwg/end-user-feedback-sessions-1": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:31.915956+01:00" + }, + "https://calendly.com/otel-euwg/end-user-feedback-sessions-2": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:32.268473+01:00" + }, + "https://calendly.com/otel-euwg/end-user-feedback-sessions-3": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:32.716301+01:00" + }, + "https://calendly.com/otel-euwg/end-user-feedback-sessions-4": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:33.226128+01:00" + }, + "https://calendly.com/otel-euwg/end-user-feedback-sessions-5": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:33.630323+01:00" + }, + "https://calendly.com/otel-euwg/humans-of-otel": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:34.021758+01:00" + }, "https://cassandra.apache.org/": { "StatusCode": 206, "LastSeen": "2024-01-30T06:06:04.662731-05:00" @@ -223,6 +251,10 @@ "StatusCode": 206, "LastSeen": "2024-01-30T06:06:13.062554-05:00" }, + "https://charity.wtf/2019/09/20/love-and-alerting-in-the-time-of-cholera-and-observability/": { + "StatusCode": 200, + "LastSeen": "2024-02-26T10:53:38.116124+01:00" + }, "https://circleci.com": { "StatusCode": 206, "LastSeen": "2024-01-30T05:18:29.78394-05:00" @@ -1103,6 +1135,10 @@ "StatusCode": 206, "LastSeen": "2024-01-18T19:56:07.640917-05:00" }, + "https://docs.kernel.org/trace/user_events.html": { + "StatusCode": 206, + "LastSeen": "2024-02-28T10:02:41.822426963+01:00" + }, "https://docs.kloudmate.com/using-opentelemetry-collector": { "StatusCode": 200, "LastSeen": "2024-01-30T15:25:17.098548-05:00" @@ -1795,6 +1831,10 @@ "StatusCode": 206, "LastSeen": "2024-01-30T05:18:17.243575-05:00" }, + "https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/project-opportunities/": { + "StatusCode": 206, + "LastSeen": "2024-02-22T11:59:59.086276+01:00" + }, "https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/": { "StatusCode": 206, "LastSeen": "2024-01-30T05:19:08.140418-05:00" @@ -2291,6 +2331,10 @@ "StatusCode": 200, "LastSeen": "2024-01-25T10:54:57.162378745Z" }, + "https://github.com/dominicfraser": { + "StatusCode": 200, + "LastSeen": "2024-02-26T10:53:39.237712+01:00" + }, "https://github.com/dotansimha/graphql-yoga": { "StatusCode": 200, "LastSeen": "2024-01-30T05:18:34.524624-05:00" @@ -2475,6 +2519,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T16:14:54.527183-05:00" }, + "https://github.com/jordibisbal8": { + "StatusCode": 200, + "LastSeen": "2024-02-26T10:53:37.290066+01:00" + }, "https://github.com/joshleecreates/": { "StatusCode": 200, "LastSeen": "2024-01-30T05:18:13.610639-05:00" @@ -3011,6 +3059,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T06:05:58.807859-05:00" }, + "https://github.com/open-telemetry/opentelemetry-demo/pull/1345": { + "StatusCode": 200, + "LastSeen": "2024-02-26T10:53:40.03196+01:00" + }, "https://github.com/open-telemetry/opentelemetry-demo/pull/432": { "StatusCode": 200, "LastSeen": "2024-01-30T15:26:30.96845-05:00" @@ -4079,6 +4131,10 @@ "StatusCode": 200, "LastSeen": "2024-01-18T20:05:14.368028-05:00" }, + "https://github.com/trillium-rs/trillium-opentelemetry": { + "StatusCode": 200, + "LastSeen": "2024-02-28T10:02:42.715380297+01:00" + }, "https://github.com/tsloughter/grpcbox": { "StatusCode": 200, "LastSeen": "2024-01-18T19:36:41.148595-05:00" @@ -4851,6 +4907,10 @@ "StatusCode": 200, "LastSeen": "2024-01-18T19:02:19.249572-05:00" }, + "https://newrelic.com/": { + "StatusCode": 206, + "LastSeen": "2024-02-26T10:53:38.368111+01:00" + }, "https://newrelic.com/blog/authors/daniel-kim": { "StatusCode": 206, "LastSeen": "2024-01-18T19:10:48.917326-05:00" @@ -5227,6 +5287,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T15:37:21.465525-05:00" }, + "https://open.substack.com/pub/geekingoutpodcast/p/opentelemetry-collector-anti-patterns": { + "StatusCode": 200, + "LastSeen": "2024-02-26T15:05:23.506868-05:00" + }, "https://opencensus.io": { "StatusCode": 206, "LastSeen": "2024-01-18T19:07:33.722102-05:00" @@ -5339,6 +5403,54 @@ "StatusCode": 200, "LastSeen": "2024-01-18T19:07:12.98586-05:00" }, + "https://opentelemetry.io/docs/collector": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:03.656226-05:00" + }, + "https://opentelemetry.io/docs/collector/": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:04.244864-05:00" + }, + "https://opentelemetry.io/docs/collector/#when-to-use-a-collector": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:04.48411-05:00" + }, + "https://opentelemetry.io/docs/collector/configuration/#connectors": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:05.306982-05:00" + }, + "https://opentelemetry.io/docs/collector/configuration/#exporters": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:06.037446-05:00" + }, + "https://opentelemetry.io/docs/collector/configuration/#processors": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:05.754871-05:00" + }, + "https://opentelemetry.io/docs/collector/configuration/#receivers": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:05.518086-05:00" + }, + "https://opentelemetry.io/docs/collector/configuration/#service-extensions": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:05.132379-05:00" + }, + "https://opentelemetry.io/docs/collector/custom-collector/": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:06.360327-05:00" + }, + "https://opentelemetry.io/docs/collector/deployment/agent/": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:04.712097-05:00" + }, + "https://opentelemetry.io/docs/collector/deployment/gateway/": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:04.939057-05:00" + }, + "https://opentelemetry.io/docs/collector/deployment/no-collector/": { + "StatusCode": 206, + "LastSeen": "2024-02-23T22:55:04.014798-05:00" + }, "https://opentracing.io": { "StatusCode": 206, "LastSeen": "2024-01-18T19:07:33.813401-05:00" @@ -6895,6 +7007,94 @@ "StatusCode": 200, "LastSeen": "2024-01-30T15:25:54.102881-05:00" }, + "https://sched.co/1YFeM": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:47.30305+01:00" + }, + "https://sched.co/1YFf5": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:56.247347+01:00" + }, + "https://sched.co/1YFfb": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:48.135727+01:00" + }, + "https://sched.co/1YFfe": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:48.869621+01:00" + }, + "https://sched.co/1YFgW": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:49.791379+01:00" + }, + "https://sched.co/1YFhI": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:50.713614+01:00" + }, + "https://sched.co/1YFhh": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:51.51307+01:00" + }, + "https://sched.co/1YFii": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:53.142854+01:00" + }, + "https://sched.co/1YFik": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:52.396065+01:00" + }, + "https://sched.co/1YFin": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:53.865358+01:00" + }, + "https://sched.co/1YFjB": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:54.712596+01:00" + }, + "https://sched.co/1YFjC": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:55.484964+01:00" + }, + "https://sched.co/1YFk3": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:57.130397+01:00" + }, + "https://sched.co/1YFk6": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:57.871734+01:00" + }, + "https://sched.co/1YGT9": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:46.547452+01:00" + }, + "https://sched.co/1YeNV": { + "StatusCode": 200, + "LastSeen": "2024-02-12T15:04:34.101672+01:00" + }, + "https://sched.co/1YeOH": { + "StatusCode": 200, + "LastSeen": "2024-02-12T15:04:34.932711+01:00" + }, + "https://sched.co/1YePA": { + "StatusCode": 200, + "LastSeen": "2024-02-12T15:04:35.781211+01:00" + }, + "https://sched.co/1YePz": { + "StatusCode": 200, + "LastSeen": "2024-02-12T15:04:36.498584+01:00" + }, + "https://sched.co/1YeSC": { + "StatusCode": 200, + "LastSeen": "2024-02-22T11:59:45.670934+01:00" + }, + "https://sched.co/1Yhf8": { + "StatusCode": 200, + "LastSeen": "2024-02-29T19:19:23.057737678Z" + }, + "https://sched.co/1YhfT": { + "StatusCode": 200, + "LastSeen": "2024-02-12T15:04:33.334624+01:00" + }, "https://seecfp.com/": { "StatusCode": 206, "LastSeen": "2024-01-18T19:10:40.056794-05:00" @@ -6935,6 +7135,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T16:15:19.756188-05:00" }, + "https://shorturl.at/qEUX1": { + "StatusCode": 200, + "LastSeen": "2024-02-28T09:18:31.267986+01:00" + }, "https://signoz.io": { "StatusCode": 206, "LastSeen": "2024-01-18T19:05:54.568865-05:00" @@ -6967,6 +7171,10 @@ "StatusCode": 206, "LastSeen": "2024-01-30T15:25:13.019086-05:00" }, + "https://sre.google/books/": { + "StatusCode": 206, + "LastSeen": "2024-02-26T10:53:38.643051+01:00" + }, "https://stackoverflow.com/questions/5626193/what-is-monkey-patching": { "StatusCode": 200, "LastSeen": "2024-01-18T19:07:28.672979-05:00" @@ -7511,6 +7719,10 @@ "StatusCode": 206, "LastSeen": "2024-01-18T19:37:16.745648-05:00" }, + "https://www.jaegertracing.io/docs/1.20/client-libraries/#propagation-format": { + "StatusCode": 206, + "LastSeen": "2024-02-28T10:02:43.157547031+01:00" + }, "https://www.jaegertracing.io/docs/1.21/client-libraries/#propagation-format": { "StatusCode": 200, "LastSeen": "2024-01-18T19:07:49.343466-05:00" @@ -8119,6 +8331,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T06:01:24.01921-05:00" }, + "https://www.skyscanner.net": { + "StatusCode": 206, + "LastSeen": "2024-02-26T10:53:37.476242+01:00" + }, "https://www.slideshare.net/Altinity/osa-con-2022-signal-correlation-the-ho11y-grail-michael-hausenblas-awspdf": { "StatusCode": 206, "LastSeen": "2024-01-18T19:56:02.307051-05:00"