Navegador compartido y OpenTelemetry en VS Code para .NET

Inicio » Software » Navegador compartido y OpenTelemetry en VS Code para .NET

Si trabajas con Visual Studio Code y te interesa sacarle todo el jugo a la IA integrada y al rendimiento de tus aplicaciones, la versión 1.119 viene cargada de cambios muy jugosos. Microsoft ha afinado tanto la parte de navegador compartido con agentes como la observabilidad basada en OpenTelemetry, dos piezas clave si usas Copilot, agentes externos como Claude o trabajas con servicios distribuidos en .NET.

En este artículo vamos a desgranar con calma qué trae esta versión: cómo funciona el nuevo navegador compartido con agentes, qué aporta la integración nativa de OpenTelemetry y cómo encaja todo esto con la observabilidad en .NET y Aspire. La idea es que tengas una visión completa, tanto si solo quieres trastear con Copilot Chat en VS Code como si estás montando un sistema distribuido serio y necesitas trazas detalladas para no ir a ciegas.

Novedades clave de Visual Studio Code 1.119

La versión 1.119 de VS Code se centra en tres frentes muy claros: mejorar las capacidades de los agentes de IA, optimizar el consumo de tokens y añadir herramientas de monitorización con OpenTelemetry. No es una actualización puramente estética; apunta directamente a cómo trabajamos con agentes inteligentes dentro del editor.

Por un lado, el navegador integrado ahora se puede compartir con los agentes de IA de forma mucho más directa, evitando el clásico baile de copiar y pegar contenido de páginas web cada vez que necesitas contexto. Por otro, Microsoft ha comenzado a usar modelos ligeros en segundo plano para gestionar parte del trabajo de los agentes y ahorrar tokens, algo crítico cuando hay límites estrictos impuestos por los proveedores de IA.

El tercer pilar es la incorporación de soporte directo de OpenTelemetry para monitorizar sesiones de agentes y herramientas asociadas como Copilot Chat, Copilot CLI y Claude. Esto abre la puerta a una observabilidad mucho más fina sobre lo que hace realmente la IA en tu flujo de trabajo.

Además de esto, la actualización introduce ajustes de seguridad en el acceso a la red para agentes y pequeños refinamientos en la vista de Markdown, pensados para que el trabajo diario con documentos y previsualizaciones sea menos engorroso.

Navegador compartido en VS Code 1.119: contexto real para la IA

Uno de los cambios más llamativos de esta versión es la forma en la que los agentes de IA pueden acceder a las pestañas del navegador embebido en VS Code. Hasta ahora, muchos usuarios se veían obligados a copiar manualmente fragmentos de HTML, el contenido del DOM o resultados de consola para que el agente entendiera qué estaba ocurriendo en una página.

Con la 1.119, puedes “anclar” una pestaña concreta del navegador integrado directamente al chat del agente. En el momento en que la marcas como compartida, esa pestaña entra en un modo de acceso conjunto, lo que permite al agente leer el contenido, seguir la navegación y, en algunos casos, interactuar con la página sin que tengas que servirle todo a cucharadas.

Esta capacidad responde a una preocupación muy extendida entre desarrolladores: los agentes veían sin problemas la terminal, pero iban prácticamente a ciegas con respecto al DOM y a la consola del navegador. Eso obligaba a perder tiempo copiando errores, nodos del DOM o salidas de consola para dárselas al asistente, algo totalmente contrario a la idea de automatizar y agilizar el flujo.

Otra mejora interesante es que los agentes ahora son conscientes del número total de pestañas abiertas, incluso de aquellas que todavía no les has compartido. Esto les permite solicitar acceso explícito a una determinada página cuando detectan que podría ser relevante. Por tu parte, puedes aceptar o rechazar ese acceso según te convenga, manteniendo el control sobre qué ve la IA en todo momento.

En la práctica, esto significa que, si estás depurando una aplicación web dentro del navegador simple de VS Code, el agente puede entender el contexto de la página, detectar errores del cliente y ayudarte sin ese intercambio manual y tedioso de información. Es un paso más hacia agentes que se comportan como verdaderos compañeros de desarrollo dentro del editor.

Optimización de tokens con modelos ligeros en segundo plano

Las plataformas de agentes se topan siempre con la misma piedra: el límite de tokens impuestos por los modelos de IA. Cada interacción, cada mensaje de contexto y cada tarea añadida consume tokens, y cuando trabajas con sesiones largas y agentes multitarea, el contador vuela.

Para aliviar esta carga, Microsoft ha introducido en VS Code 1.119 un enfoque híbrido: delegar la gestión de las listas de tareas y parte de la orquestación de los agentes en modelos más pequeños ejecutados en segundo plano. Estos modelos “ligeros” se encargan de todo lo que no sea estrictamente la ejecución principal del código o la resolución compleja que requiere un modelo grande.

De esta manera, el modelo principal se concentra en las peticiones de alto nivel y las tareas realmente complejas, mientras que el resto de la lógica de gestión —qué tarea va después, qué subtareas hay pendientes, cuándo tocar cierto fichero— se descarga en estas redes más compactas. El resultado es una reducción notable en el consumo de tokens por sesión.

Este mecanismo todavía está marcado como función experimental y viene desactivado de fábrica, por lo que si quieres usarlo tendrás que ir a la configuración de VS Code y activarlo manualmente. Tiene sentido que esté en fase de prueba, porque ajustar cuándo entra en juego el modelo ligero y cómo se reparten las responsabilidades entre modelos no es trivial.

Aunque la característica se ha planteado principalmente para agentes vinculados a Copilot y servicios similares, la idea general encaja con una tendencia más amplia en sistemas de IA: usar modelos especializados y pequeños para tareas auxiliares y dejar la carga pesada a un modelo central. Esto no solo reduce costes, también puede mejorar la latencia en determinadas operaciones.

OpenTelemetry en VS Code 1.119: monitorización de agentes y trazas

Además de las mejoras en el navegador compartido y en la gestión de tokens, Visual Studio Code 1.119 incorpora algo que a muchos equipos les hacía falta: soporte nativo para OpenTelemetry aplicado a agentes y herramientas de IA integradas. Esto convierte a VS Code en una pieza más dentro de una estrategia de observabilidad de extremo a extremo.

Microsoft subraya que, a medida que los agentes ganan autonomía, es crítico entender qué están haciendo, cuánto tardan y en qué gastan los recursos. Ya no basta con confiar en que “la magia funciona”; hace falta visibilidad detallada. Aquí es donde entra OpenTelemetry como estándar de recopilación de telemetría.

En esta versión, se exponen trazas y métricas con OpenTelemetry para tres componentes concretos: las sesiones de Copilot Chat, el agente de fondo Copilot CLI y el agente basado en Claude. A través de esta instrumentación puedes ver, por ejemplo, cómo se comportan las sesiones, qué acciones ejecutan los agentes y qué operaciones son más costosas.

La idea es poder responder preguntas muy específicas sobre el comportamiento del sistema, tales como: qué acciones ha ejecutado un agente durante una sesión, cuánto tiempo ha empleado en cada operación y qué volumen de tokens se ha consumido en cada paso. Con esta información en la mano, es mucho más sencillo ajustar configuraciones, detectar cuellos de botella o identificar patrones de uso ineficientes.

Al basarse en OpenTelemetry, estos datos pueden integrarse con backends de observabilidad estándar, tanto comerciales como de código abierto, lo que permite cruzar la telemetría de VS Code con la de otros servicios de tu arquitectura.

Qué es la observabilidad y por qué importa con OpenTelemetry

Cuando pones en marcha una aplicación —ya sea un microservicio en .NET o un sistema con agentes de IA—, lo que quieres es poder medir su comportamiento real y enterarte de los problemas antes de que exploten en producción. Para eso no basta con probar “a ojo”; necesitas telemetría continua.

En el contexto de sistemas distribuidos, la observabilidad es la capacidad de supervisar y analizar los datos de telemetría que describen el estado y el comportamiento de cada componente. A diferencia de la depuración tradicional, que suele ser invasiva y puntual, la observabilidad pretende ser lo bastante ligera como para estar siempre activa, sin distorsionar el funcionamiento normal.

Esta observabilidad se apoya en tres pilares clásicos: registros (logs), métricas y trazas distribuidas. Los registros recogen eventos concretos —una petición entrante, un error en un componente, un pedido generado—; las métricas reflejan contadores y valores de estado, como el número de solicitudes completadas o la latencia agrupada en histogramas; y el seguimiento distribuido conecta actividades a lo largo de múltiples servicios para saber dónde se invierte el tiempo y dónde aparecen los fallos.

Cada uno de estos pilares puede nutrirse de distintas fuentes: el propio entorno de ejecución (.NET runtime, recolector de basura, compilador JIT), las bibliotecas de plataforma (como Kestrel u HttpClient) y la telemetría específica de tu aplicación. Al juntar estas perspectivas, se obtiene una visión bastante completa de lo que está ocurriendo de verdad bajo el capó.

Frente al clásico “poner puntos de ruptura y cruzar los dedos”, la observabilidad bien montada permite descubrir patrones, anomalías y problemas de rendimiento a lo largo del tiempo, algo fundamental si tus servicios están desperdigados entre contenedores, cloud y agentes que toman decisiones por su cuenta.

OpenTelemetry: estándar abierto para telemetría

OpenTelemetry (OTel) se ha convertido en el estándar de facto para recoger, procesar y enviar datos de telemetría desde aplicaciones y servicios hacia sistemas de observabilidad. La ventaja es que no te casas con un proveedor concreto: defines telemetría de forma estándar y luego decides a qué backend la envías.

Este proyecto ofrece APIs para que las bibliotecas emitan datos de telemetría durante la ejecución del código, así como APIs para que los desarrolladores configuren qué subconjunto de esos datos se exporta, a dónde se envía y qué filtros o transformaciones se aplican. De ese modo puedes, por ejemplo, descartar ciertos eventos ruidosos o enriquecer las trazas con metadatos útiles.

Otro elemento clave son las convenciones semánticas, que definen cómo nombrar y estructurar los distintos tipos de señales de telemetría. Esto es vital para que una herramienta de análisis entienda qué significa cada campo y pueda generar paneles y alertas coherentes sin necesitar interpretaciones ad hoc para cada aplicación.

OpenTelemetry incluye además una interfaz para exportadores, es decir, componentes que traducen los datos recopilados a formatos concretos de cada solución APM o backend de observabilidad. Muchos proveedores ya soportan directamente OTLP, el protocolo de transporte de OpenTelemetry, además de sus formatos propietarios.

Gracias a este enfoque abierto, puedes combinar OTel con sistemas de monitorización muy variados: desde soluciones open source como Prometheus y Grafana hasta servicios gestionados como Azure Monitor y otras ofertas de APM comerciales. El mismo código instrumentado te sirve para múltiples destinos sin cambiar la lógica de negocio.

Hay implementaciones de OpenTelemetry para casi todos los lenguajes y plataformas principales, incluido .NET, donde la integración tiene matices propios debido a las APIs nativas de telemetría del framework.

Particularidades de OpenTelemetry en .NET

La implementación de OpenTelemetry en .NET es peculiar porque la plataforma ya proporciona de serie APIs de logging, métricas y actividad dentro del propio framework. Esto significa que OTel no necesita volver a inventar esas APIs para los autores de librerías; en su lugar, se apoya sobre ellas.

En la práctica, OpenTelemetry para .NET actúa como un recolector que captura la telemetría emitida por esas APIs de plataforma y por bibliotecas de instrumentación adicionales. Una vez recogidos los datos, se encargan de enviarlos al sistema de monitorización de rendimiento (APM) que tengas configurado, aplicando las convenciones y esquemas estándar de OTel.

La gran ventaja de este enfoque es que las aplicaciones no tienen que casarse con estructuras de datos propietarias de un proveedor APM concreto. Trabajan con el estándar abierto de OTel y, después, cada proveedor implementa su exportador o se conecta mediante OTLP. Así, cambiar de backend o combinar varios es mucho menos doloroso.

A nivel de paquetes, OpenTelemetry para .NET se distribuye en varias bibliotecas NuGet agrupadas en categorías: núcleo, instrumentación y exportadores. El núcleo contiene el SDK principal; los paquetes de instrumentación recopilan datos del runtime y de librerías habituales (como ASP.NET Core o HttpClient), y los exportadores hablan con sistemas como Prometheus, Jaeger o servidores OTLP.

Si estás en un entorno donde parte de la telemetría sale de procesos que no puedes recompilar, también puedes usar enfoques fuera de proceso, como EventPipe, o inyectar instrumentación mediante hooks de arranque, siguiendo los patrones de la Instrumentación automática de OpenTelemetry para .NET.

Observabilidad en .NET: estrategias y herramientas

En el ecosistema .NET existen varias vías para conseguir una observabilidad decente, y OpenTelemetry juega un papel central en casi todas. La aproximación más directa es instrumentar explícitamente el código usando bibliotecas de OTel, lo que te da un control máximo sobre qué eventos y métricas emites.

Si por cualquier motivo no tienes acceso al código fuente o no puedes recompilar, puedes recurrir a mecanismos fuera de proceso como EventPipe. Herramientas como dotnet-monitor se enganchan a los procesos en ejecución, escuchan logs y métricas y las procesan sin modificar la aplicación, algo útil en entornos donde no quieres tocar binarios en producción.

Existe además la opción de usar hooks de inicio para insertar ensamblados que añadan instrumentación automáticamente. Es el enfoque que sigue la Instrumentación automática de OpenTelemetry .NET, que permite activar telemetría sin tener que cambiar el código de las aplicaciones existentes.

Sea cual sea el enfoque, la clave es que los datos de telemetría fluyan de forma continua y estén alineados con las convenciones de OTel. Eso garantiza que las herramientas aguas abajo, desde paneles de Grafana hasta Azure Monitor, puedan explotar esa información sin demasiados malabarismos.

Combinando estas técnicas con la telemetría que ahora puede emitir VS Code 1.119 para sus agentes, puedes llegar a un escenario donde tanto tu editor como tus servicios en producción se observan con las mismas herramientas y lenguaje de telemetría, algo muy potente cuando quieres reproducir problemas localmente o seguir el rastro de una petición desde el IDE hasta el backend.

Aspire y OpenTelemetry: aplicaciones distribuidas .NET más fáciles de vigilar

Aspire es un conjunto de extensiones para .NET pensado para facilitar la creación y gestión de aplicaciones distribuidas. Una de las grandes bazas de Aspire es que ya trae la telemetría integrada de serie, basada precisamente en las bibliotecas de OpenTelemetry para .NET.

Cuando creas una solución con Aspire, las plantillas de proyecto incluyen un proyecto especial llamado ServiceDefaults. Ese proyecto encapsula toda la configuración común de OTel: SDK, instrumentación para ASP.NET, HttpClient, runtime, etcétera. Cada servicio de tu solución referencia este proyecto y lo inicializa en su arranque.

La configuración se suele centralizar en un archivo tipo Extensions.cs, donde se prepara toda la tubería de OpenTelemetry. Aspire incluye por defecto un exportador OTLP, de forma que los datos puedan visualizarse en el denominado panel de Aspire, una interfaz pensada para acercar la observación de telemetría al ciclo de depuración local.

Este panel se pone en marcha automáticamente cuando ejecutas el proyecto AppHost, ya sea desde Visual Studio (F5) o desde la línea de comandos con dotnet run sobre AppHost. Así, puedes ver en tiempo real las llamadas entre servicios, métricas y trazas mientras depuras en tu máquina, algo que antes se asociaba casi siempre al entorno de producción.

Aunque Aspire se venda como un paquete completo, puedes reutilizar solo el proyecto ServiceDefaults en aplicaciones ASP.NET que no usan el resto de la orquestación. La plantilla aspire-servicedefaults está disponible tanto en Visual Studio como a través de dotnet new, y te permite añadir rápidamente una configuración sensata de OTel a cualquier solución existente.

Una vez que agregas el proyecto ServiceDefaults a la solución y lo referencias desde tu aplicación, basta con llamar al método de configuración de OpenTelemetry durante el arranque del builder de la aplicación, por ejemplo:

var builder = WebApplication.CreateBuilder(args);

builder.ConfigureOpenTelemetry();

var app = builder.Build();

app.MapGet(«/», () => «Hello World!»);

app.Run();

Además de OTel, estos valores predeterminados pueden montar fácilmente endpoints de salud (/health y /alive), detección de servicios y reglas de resiliencia para HttpClient, como reintentos automáticos ante fallos transitorios, todo ello listo para usar.

Seguridad de red y mejoras en Markdown en VS Code 1.119

Para que las características de agentes funcionen de forma fluida, Microsoft ha introducido un ajuste que permite relajar la política de bloqueo de dominios de red. Esta configuración mantiene la idea de “sandbox” para los agentes, pero reduce el número de veces que el usuario tiene que aprobar manualmente el acceso a recursos externos.

La idea es que el entorno siga siendo seguro, pero sin interrumpir tanto el flujo de trabajo. Cuando los agentes necesitan consultar APIs o recursos en red, este ajuste puede evitar ventanas emergentes constantes pidiendo confirmación, siempre dentro de unos límites controlados.

Por otro lado, el manejo de la previsualización de Markdown se ha pulido para que sea más ágil. Se han añadido nuevas opciones y comandos que permiten alternar rápidamente entre el editor y la vista previa, algo que se agradece cuando trabajas con documentación, README o notas extensas.

En los archivos Markdown, ahora dispones de un botón “Switch to Preview View” para saltar a la vista previa, mientras que en esa vista encuentras el correspondiente “Switch to Editor View” para volver al código. No es una revolución, pero sí quita fricción en un uso diario muy habitual.

Todo esto se suma a la actualización automática habitual: VS Code 1.119 se distribuye mediante el propio sistema de actualizaciones del editor, y también se puede descargar manualmente desde la web oficial de Visual Studio Code si prefieres controlar el proceso.

Al final, el combo de navegador compartido para agentes, optimización de tokens con modelos ligeros y observabilidad basada en OpenTelemetry apunta a un escenario donde desarrollar con IA integrada y servicios distribuidos en .NET es bastante más transparente y manejable, tanto a nivel de experiencia en el editor como de monitorización en producción.