TABLE OF CONTENTS
The Instana Java SDK in version
1.2.0 brings two new major features.
It is now possible to not only create new and manage started spans by the Instana Java SDK, but also to manage spans created by Instana AutoTrace.
To do so the methods of
SpanSupport can now handle both kinds of spans.
A major use-case for this feature is adding custom annotations to automatically generated spans from known frameworks.
Furthermore, two new annotations were added to the SDK. Methods can be annotated with
@TagReturn the easily capture their return
value in the currently active span, regardless if it's an SDK or AutoTrace one. A method parameter can be annotated with
@TagParam to capture its value in the currently active span.
The Configuration-based Java Trace SDK enables a declarative approach to instrumentation that, unlike the Java Trace SDK, requires no code modification; the configuration-based nature comes at the cost of expressiveness (you can do more things with the Java Trace SDK), but it is a new tool in your arsenal ;-)
We are extending our Google Cloud Run support with .Net Core instrumentation and monitoring.
Check out our Google Cloud Run documentation to get started.
We released support for the
googleapis/java-pubsub, starting with release 1.105, and the Spring Cloud GCP for Pub/Sub, starting with version 1.2.5.RELEASE. We also added support for the Node.js client library
@google-cloud/pubsub to our Node.js tracer with
Also, we added support for the .Net Core client library Google.Cloud.PubSub.V1. All operations are automatically supported except Consume which can be supported via
Instana.Tracing.Core.Sdk. For more information, how to support Consume using SDK, please see the example here.
On Custom Dashboards, you can now group the results for area line charts and stacked bar charts. You can group by a tag and display the Top/Bottom five results on your chart widgets. If you want to know the count of the items that were not grouped, then you can also aggregate the remaining groups using the "Display aggregation of other groups" toggle. For more information and an example, please see the documentation here.
We released several improvements over the past few weeks. (As a reminder, there is a new home for the Instana agent chart in the Instana Helm Charts repository, and it is also indexed in ArtifactHub.)
- New feature: Bring-your-own secret for agent keys: using the new
agent.keysSecretsetting, you can specify the name of the secret that contains the agent key and, optionally, the download key; refer to Bring your own Keys secret for more details.
- New feature: Add support for affinities for the agent pod via the
- Improvement: Seamless support for Instana static agent images. When using an agent.image.name starting with
containers.instana.io, automatically create a secret called
_as username and
agent.downloadKeyor, if missing,
agent.keyas password. If you want to control the creation of the image pull secret, or disable it, you can use
agent.image.pullSecrets, passing to it the YAML to use for the
imagePullSecretsfield of the Daemonset spec, including an empty array
to mount no pull secrets, no matter what.
- Fix: Automatically recreate agent pods if there is a change in the ConfigMap created by this Helm chart.
Go to Settings > Account & Billing > Technologies Reporting to see the technologies you are monitoring.
Pipeline Feedback Release Markers can now be defined with a scope. The scope which can be defined are
- Service within an Application
The Release Markers will only be shown in dashboards for the given scope. The scopes can be mixed to define even complex Release Marker requirements. Read the Pipeline feedback documentation for further information.
- OpenTelemetry trace ingestion using Agent as Collector is in (early) technical preview. For more information about supported scope and setup instructions, please refer to the OpenTelemetry documentation.
- Synthetic calls: automatic detection of Spring Cloud Consul Config Watch jobs.
- Maintenance Windows: fixed problem that Incidents have not been properly filtered in case an Issue was correlated that started outside of the maintenance window's timeframe.
- Incidents: we changed the definition of the displayed start time to the point in time when the Incident is triggered, instead of the earliest start time of all correlated events. This prevents side-effects when a long-running Issue is correlated to an Incident, such as listing the new Incident in the past or showing a duration that is different from when we send open or *close+ notifications.