--- type: "article" title: "Learning: Observability" summary: "Table of Contents\n\n\n\nIntroduction\nGet Started\nCanonical logs\nTraces\nMetrics\nGeneral Best Practices\nGitHub demo repo\nConclusion\nIn this small post, I'll share some resources, notes I've taken while learning, and best practices for making our systems observable. I've always had a knowledge gap regarding observability, and recently I've truly enjoyed learning more about this area in our software industry.\nQuick note: In this post I'll only share about 3 telemetry signals. Profile is another signal that I will research in the future.\nFollow these steps to get started with auto-instrumentation in your application using OpenTelemetry: https://opentelemetry.io/docs/languages/net/getting-started/#instrumentation\nFor OpenTelemetry in a front-end app you can check these useful resources:\nGrafana faro\nNext.js\nGuide for OpenTelemetry in Next.js\nBrowser OpenTelemetry getting started\nClient-side instrumentation in OpenTelemetry is part of their roadmap which is great to see, since I've only seen vendor-specific solutions and products for front-end apps (e.g. New Relic, Datadog). For browser instrumentation otel doesn't seem to be super mature yet, but a lot of effort is being put into this area by the OpenTelemetry team.\nWe all know about logs ๐Ÿ˜„. It's data that we all need in order to troubleshoot and know what is happening in our applications. We shouldn't overdo it, creating tons and tons of logs since that will probably create noise and make it harder to troubleshoot problems.\nFor logs, we can use these best practices. From this list, these are an absolute must to follow:\nAvoid string interpolation\nUse structured logging\nLog redaction for sensitive information\nIn addition to the list above, we should also include the TraceId and SpanId in our log records, to correlate logs with traces. If you are using the Serilog console sink, by default the message template won't have those fields so if you want them, consider using JsonFormatter or CompactJsonFormatter. Here is an example Serilog configuration in appsettings.json (setup to remove unnecessary/noisy logs):\n\"Serilog\": {\n \"Using\": [\n \"Serilog.Sinks.Console\"\n ],\n \"MinimumLevel\": {\n \"Default\": \"Information\",\n \"Override\": {\n \"Microsoft.AspNetCore\": \"Warning\",\n \"Microsoft.Extensions.Diagnostics.HealthChecks\": \"Warning\"\n }\n },\n \"WriteTo\": [\n {\n \"Name\": \"Console\",\n \"Args\": {\n \"formatter\": {\n \"type\": \"Serilog.Formatting.Json.JsonFormatter, Serilog\",\n \"renderMessage\": true\n }\n }\n }\n ],\n \"Enrich\": [\n \"FromLogContext\",\n \"WithMachineName\",\n \"WithThreadId\",\n \"WithProcessId\",\n \"WithProcessName\",\n \"WithExceptionDetails\",\n \"WithExceptionStackTraceHash\",\n \"WithEnvironmentName\"\n ],\n \"Properties\": {\n \"Application\": \"GrafanaDemoOtelApp\"\n }\n }\n\nBelow are some documentation links for logging in .NET. The ILogger extension methods are not always the best choice (e.g. logger.LogInformation), especially in high-performance scenarios or if your logs are in a hot path:\nHigh-performance logging in .NET\nCompile-time logging source generation\nThere is also a different way of logging, based on having more attributes in one single log line. I've seen this in Stripe where they call it canonical log lines. Charity Majors also references this canonical logs term in her blog post about Observability 2.0 (that I reference in the Resources section).\nThis idea is very interesting, but might lack awareness. At least in .NET land, I didn't find many references to this style of logging or example code that we could follow when there are many ILogger instances involved.\nFor traces in .NET we have these best practices. So far I've seen four common solutions for adding correlation ids in traces (not all are standards):\nW3C trace context - current standard in the HTTP protocol for tracing\nX-Correlation-Id - a non-standard HTTP header for RESTful APIs (also known as X-Request-Id). I thought this was a standard since it's widely used, but I didn't find a RFC from IETF or any other organization.\nRequest-Id - this is a known header in the .NET ecosystem\nB3 Zipkin propagation - Zipkin format standard\nAWS X-Ray Trace Id - proprietary solution for AWS that adds headers for tracing\nNot every company/project uses W3C trace context, you have some options above to pick from. I prefer the standard W3C trace context ๐Ÿ˜„ (maybe the industry will widely adopt this in the future) and using OpenTelemetry to manage these headers (HTTP, AMQP, etc) and correlation with logs automatically. The code you don't write can't have bugs ๐Ÿ˜†.\nWith that said, in some situations, you might have integrations with 3rd party software and need to use their custom headers or project limitations and need to use a particular format. At the end of the day what's important is that you have distributed tracing working E2E.\nThere is also a relevant spec for distributed tracing called Baggage which OpenTelemetry implements and we can use in our apps. The most important part here is trace propagation to get the full trace from the publisher to the consumer.\nFor metrics, it's important to follow naming conventions for custom metrics. Especially if your organization has a platform team, setting conventions helps everyone. I do know some otel semantic conventions aren't stable, and that also leads to some nuget packages being pre-release.\nBut anyhow, set conventions for your team or read and follow OpenTelemetry semantic conventions.\nPrometheus best practices related to high cardinality metrics.\nWhen I started trying out custom metrics instrumentation I discovered that OpenTelemetry is not always used (the SDK + OTLP). We have the Prometheus SDK which is mature and widely used. Then for Java there are other solutions like Micrometer and others that integrate very well with Spring. In regards to the Java ecosystem, I read this otel Java benchmarks and this Spring post just because I was interested in knowing what the industry is adopting and why.\nThere is a ton to be learned with SRE principles and practices. But one in particular was very useful for me and my team: always categorize our custom metrics according to the 4 Golden Signals. Any metric we can't categorize is probably not useful for us.\nImage Credit to - Denise Yu\n \n\n\nSource of Denise Yu's art.\nGoogle's SRE book is amazing to learn more about the 4 Golden signals and creating SLO-based alerts. All our alerts should be actionable (or the support team will not be happy), so it helps if they are based on SLOs that are defined as a team.\nThey also have some best practices for production services.\nGlossary of many observability terms in case youโ€™re not familiar with them: https://github.com/prathamesh-sonpatki/o11y-wiki\n\nAwesome Observability GitHub repo\nIf dashboards make you happy check the Grafana observability report dashboard\n\nAWS observability best practices guide\nAbout RED and USE method\nTraces Instrumentation best practices in .NET\nWhat are the Limitations of Prometheus Labels?\nCNCF OpenTelemetry certification\nTAG Observability whitepaper - this is an amazing resource with tons of information! I also recommend checking out the other resources they have in the tag-observability repo and community\nResources specifically about Observability 2.0:\n\n\nObservability 2.0 by Charity Majors\nRe-Redefining Observability\nIs It Time To Version Observability? (Signs Point To Yes) - Charity Majors\nTalks\n\n\nHow Prometheus Revolutionized Monitoring at SoundCloud - Bjรถrn Rabenstein\nHow to Include Latency in SLO-based Alerting - Bjรถrn Rabenstein, Grafana Labs\nMyths and Historical Accidents: OpenTelemetry and the Future of Observability Part 1\nModern Platform Engineering: 9 Secrets of Generative Teams - Liz Fong-Jones\nContext Propagation makes OpenTelemetry awesome\nI've been developing a demo app (it has fewer features than the otel demo) to demonstrate how to build an app with OpenTelemetry, Grafana and Prometheus. It's primarily focused on a small app I can showcase in my talks.\nIf you're interested take a look:\n / \n grafana-observability-demo\n \n \n\nObservability - Grafana Demo for Talks\nThis is a simple demo showcasing how we can instrument our applications with OpenTelemetry, using Azure Monitoring + Grafana + Prometheus\nIt's intended to be used as the demo of a specific talk about observability.\nDemo app instructions\nRead the instructions in src/README.md.\nSession Abstracts\nObservability with Azure Managed Grafana\nNowadays, OpenTelemetry is used extensively to collect telemetry data from our applications, and serves as an industry standard. But we need a way to visualize this data in a clear way, and that is where Azure Managed Grafana comes in.\nIn this session we'll go through the core concepts of observability and demonstrate how we can use Azure Managed Grafana, integrated with Prometheus Grafana Tempo and Loki to gather insights from our telemetry data\nWe will cover topics such as the basics about logs, metrics and traces, manual instrumentation, OTLP, and others. We'llโ€ฆ\n\n \nView on GitHub\n\nHopefully, some of these resources I've shared are useful to you ๐Ÿ˜„. I still have a ton to learn and explore, but I'm happy with the knowledge I've acquired so far.\nThere are some specific standards + projects that I'll dive in and explore more, like: eBPF; OpenMetrics. OpenMetrics is something I'd like to spend some quality time reading about, but I know it's archived and reddit says the same. Just want to read and watch some talks about it to feed my curiosity ๐Ÿ˜ƒ.\nLast but not least, I want to follow the work that some industry leaders are doing like Charity Majors, specifically about Observability 2.0 ๐Ÿ˜„. I discovered this term in the Thouthworks tech radar, and the part \"high-cardinality event data in a single data store\" caught my interest.\nI'm still learning, researching, and listening to the opinions of industry leaders about this term to then develop my own opinions. Maybe I'll make a blog post about this in the future ๐Ÿ˜." newsletter: "David Pereira" newsletter_handle: "bolt04" newsletter_url: "https://usecommune.com/n/bolt04" author: "David Pereira (@davidpereira2938)" published: "2025-03-30T09:00:00.000Z" canonical_url: "https://usecommune.com/n/bolt04/a/learning-observability" markdown_url: "https://usecommune.com/n/bolt04/a/learning-observability.md" chat_url: "https://usecommune.com/n/bolt04/a/learning-observability/chat" source_url: "https://dev.to/bolt04/learning-observability-3i37" body_source: "imported" likes: 0 replies: 0 body_words: 1632 --- # Learning: Observability ## Table of Contents - Introduction - Get Started - Logs - Canonical logs - Traces - Metrics - General Best Practices - Resources - GitHub demo repo - Conclusion ## Introduction In this small post, I'll share some resources, notes I've taken while learning, and best practices for making our systems observable. I've always had a knowledge gap regarding observability, and recently I've truly enjoyed learning more about this area in our software industry. **Quick note**: In this post I'll only share about 3 telemetry [signals](https://opentelemetry.io/docs/concepts/signals/). **Profile** is another signal that I will research in the future. ## Get Started Follow these steps to get started with auto-instrumentation in your application using OpenTelemetry: [https://opentelemetry.io/docs/languages/net/getting-started/#instrumentation](https://opentelemetry.io/docs/languages/net/getting-started/#instrumentation) For OpenTelemetry in a front-end app you can check these useful resources: - [Grafana faro](https://grafana.com/oss/faro/) - [Next.js](https://nextjs.org/docs/app/building-your-application/optimizing/open-telemetry#using-vercelotel) - [Guide for OpenTelemetry in Next.js](https://www.checklyhq.com/blog/in-depth-guide-to-monitoring-next-js-apps-with-opentelemetry/) - [Browser OpenTelemetry getting started](https://opentelemetry.io/docs/languages/js/getting-started/browser/) Client-side instrumentation in OpenTelemetry is part of [their roadmap](https://opentelemetry.io/community/roadmap/#p2-client-instrumentation-rum) which is great to see, since I've only seen vendor-specific solutions and products for front-end apps (e.g. New Relic, Datadog). For browser instrumentation otel doesn't seem to be super mature yet, but a lot of effort is being put into this area by the OpenTelemetry team. ## Logs We all know about logs ๐Ÿ˜„. It's data that we all need in order to troubleshoot and know what is happening in our applications. We shouldn't overdo it, creating tons and tons of logs since that will probably create noise and make it harder to troubleshoot problems. For logs, we can use [these best practices](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/docs/logs/README.md#best-practices). From this list, these are an absolute must to follow: - Avoid string interpolation - Use structured logging - Log redaction for sensitive information In addition to the list above, we should also include the `TraceId` and `SpanId` in our log records, to correlate logs with traces. If you are using the Serilog console sink, [by default the message template](https://github.com/serilog/serilog-sinks-console/blob/4c9a7b6946dfd2d7f07a792c40bb3d46af835ee9/src/Serilog.Sinks.Console/ConsoleLoggerConfigurationExtensions.cs#L32) won't have those fields so if you want them, consider using [JsonFormatter](https://github.com/serilog/serilog/wiki/Formatting-Output#formatting-json) or `CompactJsonFormatter`. Here is an example Serilog configuration in `appsettings.json` (setup to remove unnecessary/noisy logs): ``` "Serilog": { "Using": [ "Serilog.Sinks.Console" ], "MinimumLevel": { "Default": "Information", "Override": { "Microsoft.AspNetCore": "Warning", "Microsoft.Extensions.Diagnostics.HealthChecks": "Warning" } }, "WriteTo": [ { "Name": "Console", "Args": { "formatter": { "type": "Serilog.Formatting.Json.JsonFormatter, Serilog", "renderMessage": true } } } ], "Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId", "WithProcessId", "WithProcessName", "WithExceptionDetails", "WithExceptionStackTraceHash", "WithEnvironmentName" ], "Properties": { "Application": "GrafanaDemoOtelApp" } } ``` Below are some documentation links for logging in .NET. The `ILogger` extension methods are not always the best choice (e.g. `logger.LogInformation`), especially in high-performance scenarios or if your logs are in a hot path: - [High-performance logging in .NET](https://learn.microsoft.com/en-us/dotnet/core/extensions/high-performance-logging) - [Compile-time logging source generation](https://learn.microsoft.com/en-us/dotnet/core/extensions/logger-message-generator) ### Canonical logs There is also a different way of logging, based on having more attributes in one single log line. I've seen this in Stripe where they call it [canonical log lines](https://stripe.com/blog/canonical-log-lines). Charity Majors also references this **canonical logs** term in her blog post about Observability 2.0 (that I reference in the Resources section). This idea is very interesting, but might lack awareness. At least in .NET land, I didn't find many references to this style of logging or example code that we could follow when there are many `ILogger` instances involved. ## Traces For traces in .NET we have [these best practices](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs#best-practices-1). So far I've seen four common solutions for adding [correlation ids](https://microsoft.github.io/code-with-engineering-playbook/observability/correlation-id/) in traces (not all are standards): - [W3C trace context](https://www.w3.org/TR/trace-context/) - current standard in the HTTP protocol for tracing - [X-Correlation-Id](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non-standard_request_fields) - a non-standard HTTP header for RESTful APIs (also known as [X-Request-Id](https://http.dev/x-request-id)). I thought this was a standard since it's widely used, but I didn't find a RFC from IETF or any other organization. - [Request-Id](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md) - this is a known header in the .NET ecosystem - [B3 Zipkin propagation](https://github.com/openzipkin/b3-propagation) - Zipkin format standard - [AWS X-Ray Trace Id](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader) - proprietary solution for AWS that adds headers for tracing Not every company/project uses W3C trace context, you have some options above to pick from. I prefer the standard W3C trace context ๐Ÿ˜„ (maybe the industry will widely adopt this in the future) and using OpenTelemetry to manage these headers (HTTP, AMQP, etc) and correlation with logs automatically. The code you don't write can't have bugs ๐Ÿ˜†. With that said, in some situations, you might have integrations with 3rd party software and need to use their custom headers or project limitations and need to use a particular format. At the end of the day what's important is that you have distributed tracing working E2E. There is also a relevant spec for distributed tracing called [Baggage](https://www.w3.org/TR/baggage/) which OpenTelemetry implements and we can use in our apps. The most important part here is trace propagation to get the full trace from the publisher to the consumer. ## Metrics For metrics, it's important to follow naming conventions for custom metrics. Especially if your organization has a platform team, setting conventions helps everyone. I do know some otel semantic conventions aren't stable, and that also leads to some nuget packages being pre-release. But anyhow, set conventions for your team or read and follow [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/general/metrics/). An important resource I found is the comments on [Prometheus best practices](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels) related to high cardinality metrics. When I started trying out custom metrics instrumentation I discovered that OpenTelemetry is not always used (the SDK + OTLP). We have the Prometheus SDK which is mature and widely used. Then for Java there are other solutions like Micrometer and others that integrate very well with Spring. In regards to the Java ecosystem, I read [this otel Java benchmarks](https://opentelemetry.io/blog/2024/java-metric-systems-compared/#benchmark-opentelemetry-java-vs-micrometer-vs-prometheus-java) and [this Spring post](https://spring.io/blog/2024/10/28/lets-use-opentelemetry-with-spring) just because I was interested in knowing what the industry is adopting and why. ## General Best Practices There is a ton to be learned with SRE principles and practices. But one in particular was very useful for me and my team: **always categorize our custom metrics according to the 4 Golden Signals**. Any metric we can't categorize is probably not useful for us. ![Image Credit to - Denise Yu](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdeniseyu.io%2Fart%2Fsketchnotes%2Ftopic-based%2Fmonitoring.png)Image Credit to - Denise Yu [Source of Denise Yu's art](https://deniseyu.io/art/). [Google's SRE book](https://sre.google/sre-book/monitoring-distributed-systems/) is amazing to learn more about the 4 Golden signals and creating SLO-based alerts. All our alerts should be actionable (or the support team will not be happy), so it helps if they are based on SLOs that are defined as a team. They also have [some best practices for production services](https://sre.google/sre-book/service-best-practices/). ## Resources - Glossary of many observability terms in case youโ€™re not familiar with them: [https://github.com/prathamesh-sonpatki/o11y-wiki](https://github.com/prathamesh-sonpatki/o11y-wiki) - [Awesome Observability GitHub repo](https://github.com/magsther/awesome-opentelemetry) - If dashboards make you happy [check the Grafana observability report dashboard](https://play.grafana.org/d/feg4yc4qw3wn4b/third-annual-observability-survey?pg=survey-2025&plcmt=toc-cta-2&orgId=1&from=2025-03-13T02:49:20.476Z&to=2025-03-14T02:49:20.476Z&timezone=utc&var-region=$__all&var-role=$__all&var-size=$__all&var-industry=$__all&var-filters=%60Region%60%20in%20%28%27Europe%27,%27Asia%27,%27North%20America%27,%27Africa%27,%27South%20America%27,%27Oceania%27,%27Middle%20East%27%29%20AND%20%60Role%60%20IN%20%28%27Platform%20team%27,%27SRE%27,%27CTO%27,%27Engineering%20manager%27,%27Developer%27,%27Director%20of%20engineering%27,%27Other%27%29%20AND%20%60Size_of_organization%60%20IN%20%28%2710%20or%20fewer%20employees%27,%2711%20-%20100%20employees%27,%27101%20-%20500%20employees%27,%27501%20-%201,000%20employees%27,%271,001%20-%202,500%20employees%27,%272,501%20-%205,000%20employees%27,%275,001%2B%20employees%27%29%20AND%20%60Industry%60%20IN%20%28%27Telecommunications%27,%27Healthcare%27,%27IoT%27,%27Financial%20services%27,%27Education%27,%27Government%27,%27Applied%20Sciences%27,%27Software%20%26%20Technology%27,%27Media%20%26%20Entertainment%27,%27Travel%20%26%20Transportation%27,%27Retail%2FE-commerce%27,%27Energy%20%26%20Utilities%27,%27Automotive%20%26%20Manufacturing%27,%27Other%27%29) - [AWS observability best practices guide](https://aws-observability.github.io/observability-best-practices/guides/) - [About RED and USE method](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/) - [Traces Instrumentation best practices in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs#best-practices-1) - [What are the Limitations of Prometheus Labels?](https://signoz.io/guides/what-are-the-limitations-of-prometheus-labels/#what-are-the-limitations-of-prometheus-labels) - [CNCF OpenTelemetry certification](https://www.cncf.io/training/certification/otca/) - [TAG Observability whitepaper](https://github.com/cncf/tag-observability/blob/main/whitepaper.md) - this is an amazing resource with tons of information! I also recommend checking out the other resources they have in the tag-observability repo and community - Resources specifically about **Observability 2.0**: - [Observability 2.0 by Charity Majors](https://charity.wtf/tag/observability-2-0/) - [Re-Redefining Observability](https://www.aparker.io/post/3leq2g72z7r2t) - [Is It Time To Version Observability? (Signs Point To Yes) - Charity Majors](https://www.youtube.com/watch?v=ag2ykPO805M) - Talks - [How Prometheus Revolutionized Monitoring at SoundCloud - Bjรถrn Rabenstein](https://www.youtube.com/watch?v=hhZrOHKIxLw) - [How to Include Latency in SLO-based Alerting - Bjรถrn Rabenstein, Grafana Labs](https://www.youtube.com/watch?v=X99X-VDzxnw) - [Myths and Historical Accidents: OpenTelemetry and the Future of Observability Part 1](https://www.youtube.com/watch?v=pLPMAAOSxSE) - [Modern Platform Engineering: 9 Secrets of Generative Teams - Liz Fong-Jones](https://youtu.be/3tBj3ZCPGJY?t=687) - [Context Propagation makes OpenTelemetry awesome](https://www.youtube.com/watch?v=gviWKCXwyvY) ### GitHub demo repo I've been developing a demo app (it has fewer features than the [otel demo](https://github.com/open-telemetry/opentelemetry-demo)) to demonstrate how to build an app with OpenTelemetry, Grafana and Prometheus. It's primarily focused on a small app I can showcase in my talks. If you're interested take a look: ## ![GitHub logo](https://assets.dev.to/assets/github-logo-5a155e1f9a670af7944dd5e12375bc76ed542ea80224905ecaf878b9157cdefc.svg) [BOLT04](https://github.com/BOLT04) / [grafana-observability-demo](https://github.com/BOLT04/grafana-observability-demo) ### Repo with grafana and observability related demo app # Observability - Grafana Demo for Talks This is a simple demo showcasing how we can instrument our applications with OpenTelemetry, using Azure Monitoring + Grafana + Prometheus It's intended to be used as the demo of a specific talk about observability. ## Demo app instructions Read the instructions in `src/README.md`. ## Session Abstracts ### Observability with Azure Managed Grafana Nowadays, OpenTelemetry is used extensively to collect telemetry data from our applications, and serves as an industry standard. But we need a way to visualize this data in a clear way, and that is where Azure Managed Grafana comes in. In this session we'll go through the core concepts of observability and demonstrate how we can use Azure Managed Grafana, integrated with Prometheus Grafana Tempo and Loki to gather insights from our telemetry data We will cover topics such as the basics about logs, metrics and traces, manual instrumentation, OTLP, and others. We'llโ€ฆ [View on GitHub](https://github.com/BOLT04/grafana-observability-demo) ## Conclusion [![happy gif](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F14piw6dnmu0v0vh6b51t.gif)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F14piw6dnmu0v0vh6b51t.gif) Hopefully, some of these resources I've shared are useful to you ๐Ÿ˜„. I still have a ton to learn and explore, but I'm happy with the knowledge I've acquired so far. There are some specific standards + projects that I'll dive in and explore more, like: eBPF; OpenMetrics. OpenMetrics is something I'd like to spend some quality time reading about, but I know [it's archived](https://www.cncf.io/blog/2024/09/18/openmetrics-is-archived-merged-into-prometheus/) and [reddit says the same](https://www.reddit.com/r/devops/comments/1f5ttdx/openmetrics_is_archived_merged_into_prometheus/?rdt=47070). Just want to read and watch some talks about it to feed my curiosity ๐Ÿ˜ƒ. Last but not least, I want to follow the work that some industry leaders are doing like [Charity Majors](https://charity.wtf/), specifically about Observability 2.0 ๐Ÿ˜„. I discovered this term in the [Thouthworks tech radar](https://www.thoughtworks.com/radar/techniques/summary/observability-2-0), and the part "high-cardinality event data in a single data store" caught my interest. I'm still learning, researching, and listening to the opinions of industry leaders about this term to then develop my own opinions. Maybe I'll make a blog post about this in the future ๐Ÿ˜. *** ## Discussion No replies yet.