Forem: New Relic

Build AI Agents You Can Actually Trust — Hackathon in Mountain View 🚀

Harry Kimpel — Wed, 11 Mar 2026 20:12:07 +0000

You Founded a Startup. Your AI Agents Are Hallucinating. Your Investors Are Watching

Sound fun? It is, actually.

On March 27, we're hosting a free, in-person hackathon at the Microsoft Mountain View Campus (1045 La Avenida St, Mountain View, CA) where you'll build an AI-powered travel planning assistant from scratch — and then make it production-ready with real observability and security controls.

This is part of Microsoft's What The Hack series: collaborative, challenge-based hackathons where you learn by doing, not by watching someone else's screen.

🌍 The Scenario: Welcome to WanderAI

You've just founded WanderAI, a travel planning startup. Your customers describe their dream trip, and your AI agents craft personalized itineraries.

But here's the catch — your investors want answers:

🔍 Are the agents making good recommendations?
⚡ How fast are they responding?
🚨 When something breaks, can we debug it?
✅ Are the travel plans actually... good?

Your mission: go from "cool demo" to "production-ready AI service" in a single day.

🛠️ What You'll Build (and Learn)

The hack is structured as 8 progressive challenges:

#	Challenge	What You'll Do
00	Prerequisites	Set up your GitHub Codespace
01	Master the Foundations	Understand agent architecture, tools & orchestration
02	Build Your MVP	Create a Flask web app + your first AI agent with tool calling
03	Add OpenTelemetry	Instrument with built-in telemetry, verify traces in console & New Relic
04	New Relic Integration	Custom spans, metrics, and correlated logging
05	Monitoring Best Practices	Dashboards, alerting, and production monitoring patterns
06	LLM Quality Gates	Build evaluation tests and CI/CD quality gates for AI outputs
07	Platform Security	Configure Microsoft Foundry Guardrails
08	App-Level Security	Prompt injection detection and blocking

By the end, you'll have a fully instrumented, observable, and secure multi-agent AI system. Not bad for one day.

🧰 The Tech Stack

Microsoft Agent Framework — for building multi-agent orchestrations
OpenTelemetry — the open standard for traces, metrics, and logs
New Relic — for sending, visualizing, and alerting on all that telemetry
Azure — the cloud backbone
Python + Flask — the app layer
GitHub Codespaces — zero local setup headaches

🍕 The Details

When: March 27, 2026
Where: Microsoft Mountain View Campus, 1045 La Avenida St, Mountain View, CA
Cost: Free
Food: Provided
Duration: ~3–5 hours
What to bring: Your laptop and curiosity

Who Is This For?

Anyone who's building (or thinking about building) AI agents and wants to understand what's happening under the hood. Whether you're a backend engineer, an ML practitioner, a platform engineer, or just AI-curious — this hack meets you where you are.

No prior experience with New Relic or OpenTelemetry is required. Basic Python and web dev knowledge is helpful.

🎟️ Register Now

Space is limited — grab your seat before it fills up:

👉 Register here

See you in Mountain View! 🏔️

Unleashing the Power of Monitoring: Master Your WordPress with New Relic

Harry Kimpel — Tue, 25 Nov 2025 19:58:22 +0000

WordPress powers countless websites across various domains, offering incredible versatility. This Content Management System (CMS) is the undisputed leader in the CMS market, powering an impressive 43.6% of all websites globally, according to these statistics. With over 810 million websites built on the platform and hundreds more launching daily (500+), its adoption continues to surge. This widespread use gives WordPress a massive 62% CMS market share, significantly outpacing its rivals.

However, even the most robust WordPress sites can face performance challenges. Slowdowns are often caused by factors such as slow-loading plugins, database connection issues, infrastructure capacity problems, network trouble, large page assets (like images or fonts), and broken links. This is why robust monitoring is essential for maintaining a fast, reliable, and user-friendly website.

The question now is: what should be monitored in WordPress?

To truly master your WordPress environment, monitoring needs to extend across the entire stack:

WordPress Application Code: The core of your site and any custom code or plugins you've added.
Underlying Infrastructure: This includes the hosts, servers, or virtual machines (VMs) that power your site.
(Apache) Web Server: Monitoring the web server ensures it's handling requests efficiently.
(MySQL) Database: Database performance is critical, as slow queries can quickly bottleneck your site.
End-User Experience (Frontend): How your website performs for your actual users, measuring factors like page load times.
Business Objectives: Tracking metrics like visitor count, device usage, and post performance, which tie directly to your business goals.

How to Monitor WordPress

You have several powerful options for implementing comprehensive WordPress monitoring:

1. New Relic Observability Platform

New Relic offers a powerful full-stack WordPress integration that monitors your application's performance. It helps you diagnose issues and optimize your code by leveraging New Relic's existing PHP, Apache, and MySQL integrations. This provides pre-built dashboards with crucial metrics like transactions, visitors, and call duration. The installation process is often surprisingly quick, with agents installed in minutes.

2. OpenTelemetry (Open-Source Standard)

OpenTelemetry (CNCF project) is a vendor-agnostic set of APIs, libraries, and a collector service designed to standardize how you collect telemetry data (Traces, Metrics, and Logs) from your applications.

Traces: Show the path of a request through your application and services.
Metrics: A measurement captured at runtime, such as Avg. CPU, Throughput, or Max. Memory.
Logs: A recording of an event.

The OpenTelemetry WordPress extension monitors performance and, unlike some WordPress setups, relies on a composer for managing dependencies, including the OpenTelemetry SDK and an exporter to send telemetry data to an observability platform of your choice.What Monitoring Reveals

Benefits of WordPress monitoring

Implementing monitoring gives you deep visibility into your site's performance:

Frontend Monitoring

This focuses on the user experience, revealing how quickly pages load and identifying performance bottlenecks visible to the end-user.

New Relic monitoring capabilities automatically include Google’s lighthouse metrics.

This allows you to either visualize a comparison between frontend and backend duration or dive deeper into the breakdowns of the frontend sections of your page view load time.

Another key aspect of frontend aka real user monitoring is New Relic’s Geography UI page. It provides a world view with color-coded performance information about your frontend experience in cities, regions, and countries anywhere around the world. The map shows your user data by region, so you can visualize your traffic and error hotspots alongside device type information. You can also examine critical Core Web Vitals data so that you can prioritize areas around the globe needing attention.

Backend Analysis

Monitoring provides detailed insight into your server-side performance, allowing you to examine:

Golden Signals: Web transaction time, throughput, errors

Especially when seeing spikes, a timeseries view provides visual representations of patterns and anomalies.

Transactions: The processing time for various key requests

Database: Slow or inefficient database queries

Hooks: Performance of WordPress action and filter hooks

Traces: Detailed views of a single request's journey through your system

Business Metrics

Beyond technical performance, monitoring allows you to track metrics that directly impact your business:

Visitors: Analyze user traffic and trends

Devices: See which devices your visitors are using

Posts: Monitor the performance and traffic of specific content

Backend Users: Track activity and performance related to logged-in users and administrators.

Conclusion: Why, What, and How

Effective WordPress monitoring answers three key questions:

Why Monitor? To resolve slowdowns, address infrastructure issues, and ensure a positive end-user experience.
What to Monitor? The technical aspects (code, infrastructure, database), the end-user experience, and business objectives.
How to Monitor? By utilizing powerful options like the New Relic observability platform or the vendor-agnostic OpenTelemetry standard.

Ultimately, monitoring is about understanding where your application is excelling and where it needs attention, allowing you to proactively optimize performance and achieve your business goals.

Ready to gain deep insights into your WordPress performance?

Get started with New Relic today and leverage the power of comprehensive observability, whether through our native integrations or the flexibility of OpenTelemetry.

Optimizing Kafka Tracing with OpenTelemetry: Boost Visibility & Performance

Harry Kimpel — Tue, 25 Nov 2025 19:55:31 +0000

Ideally, you should be using distributed tracing to trace requests through your system, but Kafka decouples producers and consumers, which means there are no direct transactions to trace between them. Kafka also uses asynchronous processes, which have implicit, not explicit, dependencies. That makes it challenging to understand how your microservices are working together.

However, it is possible to monitor your Kafka clusters with distributed tracing and OpenTelemetry. You can then analyze and visualize your traces in an open-source distributed tracing tool like Jaeger or a full observability platform like New Relic. In this post, I will leverage a simple application to show how you can achieve this.

Design Considerations & Guidelines

OpenTelemetry typically comes in two flavors:

When I talk about these flavors, I typically use the analogy above. You can either buy a ready-made cake and enjoy it or buy all the ingredients and make the cake yourself. With OpenTelemetry, the approach is very similar and the flavors are:

Zero-code instrumentation: in this approach, you will use an OpenTelemetry agent and attach it to your application at startup time. This agent will then do its magic and automatically (without any source code changes) provide a lot of telemetry signals (metrics, traces and logs) and insights into your application.
- Pros:
- Getting started quickly
- No source code changes
- Cons:
- Limited customization
- Depth of visibility into your application may be limited
Manual instrumentation: this option requires you to add some dependencies and packages to your source code that you need to manage as part of your regular software development lifecycle (SDLC). However, this also allows you to be more specific and custom about your instrumentation. You can easily add custom metrics, traces, attributes to your telemetry.
- Pros:
- Way more flexible with customizing telemetry
- Easily able to add, remove and tweak the depth of your instrumentation
- Cons:
- Dependencies in your source code
- More effort to implement

Sample application

The sample application (available in this public GitHub repository) that I am using in this blog is based on this high-level architecture:

It contains these components:

kafka-java-producer: a Java Spring Boot application that produces messages into a Kafka topic
Kafka broker
kafka-java-consumer: a Java Spring Boot application that subscribes to a Kafka topic and reads messages from it. This component also makes calls to an external REST API service (that is not in our control)
kafka-java-service: a downstream Java Spring Boot application that is being called from the consumer service

Zero-code instrumentation

Let’s start with zero-code instrumentation, aka automatic instrumentation.

Configuration

Each of the different services contain a run.sh script to get the service up and running. The script looks like this:

The key line in this is the first one. Here we are defining the JAVA_TOOL_OPTIONS and configuring the -javaagent to point to the location of the OpenTelemetry Java agent.

The next three lines configure how we want to deal with the different telemetry signals. In our case, I define the traces, metrics and logs to be exported via OpenTelemetry Line Protocol (OTLP).

There are three additional environment variables that are quite important to configure:

OTEL_EXPORTER_OTLP_ENDPOINT: the target system where we want to export the data to, i.e. our telemetry backend. In my case, this is for sure New Relic and so I configure New Relic’s native OTLP endpoint
OTEL_EXPORTER_OTLP_HEADERS: the above exporter endpoint is an open API, so we need to configure an API key. In the case of New Relic, this is a New Relic license key.
OTEL_SERVICE_NAME: ideally, we want to give the service a meaningful name, so that New Relic can create an appropriate entity from it.

This is basically all we need to configure. Everything else is dealt by the OpenTelemetry Java agent. No need to change anything in our source code.

Observability

Let’s see what level of visibility into the services we can achieve from zero-code instrumentation.

When navigating to my New Relic account, I can see all services reporting into separate entities.

Let’s start by exploring the kafka-java-producer service.

The Summary view offers a great overview of all the most important telemetry and metrics I should be focusing on.

As part of this blog, I am mostly interested in the Distributed Tracing section, so let’s dive deeper into this area.

By looking at a single trace, this allows me to view the detailed information on how long this specific trace took to execute and where the time was spent.

We also automatically draw an Entity map of all the different services involved in a given trace.

The interesting area that I want to draw your attention to lies in the trace and span breakdown. You can see how the trace gets initiated on the producer, the consumer then picks up the message and how the consumer then also makes two separate calls to the downstream service.

What is interesting here is the span that says “Uninstrumented time”. This is code in the consumer where the agent was not able to capture some more detailed information about what is going on in its internal methods.

This already shows the limits of zero-code instrumentation. The agent by default will not instrument all the various methods and source code, but rather stops - by design - at some level to get deeper visibility into your code.

Manual instrumentation

In the previous section, you saw how zero-code instrumentation has some limits when it comes to visibility into your application. This is exactly where manual instrumentation comes into play.

Configuration

I have configured the same application, but this time, no agent at all is configured when starting the application.

I simply use the Maven wrapper to run the application.

The other configuration details are then part of my application.properties:

These properties are then used in my Spring Boot application code to define the configuration for OpenTelemetry for traces, metrics and logs.

Observability

Before I jump into the details of how I implemented some manual instrumentation, let’s have a look at the result first.

Do you notice how the span, which previously was called out with “Uninstrumented time”, now shows much more detailed information? I now can see these additional spans:

ExecuteLongRunningTask
WhyTheHeckDoWeSleepHere
SomeTinyTask
AnotherShortRunningTask

The one that says “WhyTheHeckDoWeSleepHere” seems to be taking the most time. No wonder, as the name suggests 😉.

Let’s have a look at the source code to reveal the manual instrumentation I put in place.

In the method named ExecuteLongRunningTask I have created a new span on the current tracer by using the spanBuilder() Method.

In addition to that, you may also notice that - just for the fun of it - I created another span called “WhyTheHeckDoWeSleepHere” that contains an artificial unit of work or rather a sleep instruction on the current thread.

These concepts to leverage the OpenTelemetry SDK allow me to be much more specific in getting insights and details into my application and source code. But, as you can imagine, also have the caveat that I need to have some dependencies and custom code available in my source code.

Conclusion

I hope I was able to show you how easy it can be to leverage OpenTelemetry in order to get insights into your application and services. We looked into zero-code instrumentation to get started without any code changes, but the level of details may be limited. We then also looked into manual instrumentation. This allowed us to be more specific and customize the instrumentation, but the effort to get started is a little higher.

I encourage you to have a look into OpenTelemetry and its fascinating capabilities. Let me know your thoughts and please get in touch if you have any questions or need further information.

Happy coding!

Monitoring PM2 in production

Zameer Fouzan — Fri, 01 Nov 2024 13:30:00 +0000

In large-scale Node.js production environments, monitoring multiple applications can become challenging. The New Relic APM agent for Node.js helps capture logs, traces, and in-depth performance metrics from individual applications. But what about the overall health and resource consumption of all Node.js processes themselves, and critical process-level metrics like CPU and memory usage?

PM2 is a popular process manager for Node.js applications, designed to simplify deployment and ensure reliability. It provides robust features, including automatic application restarts, load balancing, and monitoring capabilities, making it an essential tool for managing production-grade Node.js environments.

PM2's monitoring API provides easy access to detailed telemetry data, like active processes, and resource consumption, along with additional helpful details like Git commit, active branch, Node.js version, and entry script. These insights can be invaluable when troubleshooting and identifying the root cause of performance issues.

What can I monitor from PM2?

PM2 API provides generous information that can be captured. Ideally, all the metrics that can be visualized using the PM2’s monitor API on your host can be captured and exported to New Relic.

In this blog post, we’ll focus on several key metrics that are important for monitoring PM2.

Application identity and host information

Application details, including the host ID, for applications currently running as part of PM2, make it easy to pinpoint which instance is associated with each application. This is especially helpful in environments with multiple services, as you can easily identify specific processes and manage them effectively.

Metrics: appName, hostId

Resource metrics

Metrics from each process, like CPU and memory usage, provide essential insights into the resource consumption and performance of your application. With axm_monitor, you can also track HTTP latency, active requests, and event loop latency to monitor responsiveness in real time.

Metrics: monit.cpu, monit.memory, axm_monitor (for example, HTTP latency, active requests, event loop latency)

Process information

Process-level details such as process ID, status, and uptime help monitor each application's health and lifecycle. Tracking when a process was last updated or started helps you identify issues like frequent restarts or unusually high uptime.

Metrics: pid, pm2_env.status, pm2_env.pm_uptime, pm2_env.created_at, timestamp, pm2_env.update_time

Debug pointers: Logs, errors, restarts, and crashes

Debugging details like log paths, error codes, and restart counts allow quick troubleshooting. Having both the standard output and error logs, alongside information on restarts, helps pinpoint stability issues or potential bugs within applications.

Metrics: pm2_env.error_file, pm2_env.out_file, pm2_env.exit_code, pm2_env.unstable_restarts, pm2_env.restart_time, pm2_env.status

Version control and deployment insights

Deployment details, including Git commit history and Node.js version, make it easy to track deployed versions. PM2 captures branch, revision, and commit data, giving clear visibility into which version is running and simplifying root cause analysis after code changes.

Metrics: pm2_env.node_version, pm2_env.version, pm2_env.versioning.*

How do I capture insights from PM2?

Currently, there’s no direct integration between New Relic agents and PM2, but we can build our own integration using Flex. Flex is an easy and agentless option to build integrations between your data source and New Relic.

Configuration

Create a new configuration file named pm2_monit.yml, then add the following configuration.

This configuration is simply calling the PM2 jlist API and sanitizing the JSON output data using JQ. JQ is a command line utility that's used to process, query, and transform JSON data. Flex has support for JQ built in, which makes sanitizing and transforming the data easier.

As the original output can also include additional, sensitive data, which could be unnecessary, it can be easily dropped with the JQ and remove_keys functions of Flex.

Basic configuration

integrations:
  - name: nri-flex
    timeout: 60s
    interval: 30s
    config:
      name: PM2status
      apis:
        - name: PM2Process
          event_type: PM2Sample
          commands:
        # Linux specific command
            - run: USER=ubuntu; su - $USER bash -c "pm2 jlist"
        # command for windows/mac
        # - run: npx pm2 jlist

JSON transformation with JQ

At this stage, the output from pm2 jlist is a raw JSON. Let’s sanitize and transform the JSON output with JQ to retain only the necessary fields, using the remove_keys and rename_keys functions to streamline the data further:

       # Sanitize and transform the JSON output to required format   
          jq: >- 
              [] | { 
                  pid,
                  name,
                  pm2_env: {
                    script: .pm2_env.script?,
                    out_file: .pm2_env.out_file?,
                    error_file: .pm2_env.error_file?,
                    watch: .pm2_env.watch?,
                    exit_code: .pm2_env.exit_code?,
                    node_version: .pm2_env.node_version?,
                    versioning: .pm2_env.versioning?,
                    version: .pm2_env.version?,
                    unstable_restarts: .pm2_env.unstable_restarts?,
                    restart_time: .pm2_env.restart_time?,
                    created_at: .pm2_env.created_at?,
                    pm_uptime: .pm2_env.pm_uptime?,
                    status: .pm2_env.status?,
                    unique_id: .pm2_env.unique_id?
                  },
                  pm_id,
                  monit
                } | del(.pm2_env.versioning.remotes) 
          remove_keys:
            - pm_id
          rename_keys:
            name: appName
          custom_attributes:
            hostId: localhost

Switching user context

The command block in Flex configuration switches the user context to where PM2 processes are running, which is necessary, as Flex runs under the root (sudo) user by default. If you're running PM2 locally on Windows or Mac, use npx pm2 jlist command block instead of the Linux-specific command.

The complete configuration should look like this:

integrations:
  - name: nri-flex
    timeout: 60s
    interval: 30s
    config:
      name: PM2status
      apis:
        - name: PM2Process
          event_type: PM2Sample
          commands:
            - run: USER=ubuntu; su - $USER bash -c "pm2 jlist"
        # - run: npx pm2 jlist
       # Sanitize and transform the JSON output to required format   
          jq: >- 
              [] | { 
                  pid,
                  name,
                  pm2_env: {
                    script: .pm2_env.script?,
                    out_file: .pm2_env.out_file?,
                    error_file: .pm2_env.error_file?,
                    watch: .pm2_env.watch?,
                    exit_code: .pm2_env.exit_code?,
                    node_version: .pm2_env.node_version?,
                    versioning: .pm2_env.versioning?,
                    version: .pm2_env.version?,
                    unstable_restarts: .pm2_env.unstable_restarts?,
                    restart_time: .pm2_env.restart_time?,
                    created_at: .pm2_env.created_at?,
                    pm_uptime: .pm2_env.pm_uptime?,
                    status: .pm2_env.status?,
                    unique_id: .pm2_env.unique_id?
                  },
                  pm_id,
                  monit
                } | del(.pm2_env.versioning.remotes) 
          remove_keys:
            - pm_id
          rename_keys:
            name: appName
          custom_attributes:
            hostId: localhost

Validation

Once the configuration is ready, we can validate it with Flex's debug mode. If you’re using the standalone binary mode of Flex, use the following command to test your configuration:

sudo ./nri-flex -config_file pm2_monit.yml --pretty --verbose

To test the configuration using New Relic's infrastructure agent Flex integration, execute the following command:

sudo /var/db/newrelic-infra/newrelic-integrations/bin/nri-flex --verbose --pretty --config_file ./pm2_monit.yml

Read more about Flex testing and debugging in this document.

Upon successful execution of your configuration, you should expect an output similar to the one displayed below, without the Flex debug output:

{
    "name": "com.newrelic.nri-flex",
    "protocol_version": "3",
    "integration_version": "1.15.2",
    "data": [
        {
            "metrics": [
                {
                    "appName": "expressApp-otel",
                    "event_type": "PM2Sample",
                    "hostId": "ec2-webserver",
                    "integration_name": "com.newrelic.nri-flex",
                    "integration_version": "1.15.2",
                    "monit.cpu": 0,
                    "monit.memory": 46641152,
                    "pid": 1304,
                    "pm2_env.created_at": 1728589283166,
                    "pm2_env.error_file": "logs/error.log",
                    "pm2_env.exit_code": 1,
                    "pm2_env.node_version": "16.17.0",
                    "pm2_env.out_file": "logs/app.log",
                    "pm2_env.pm_uptime": 1729058602005,
                    "pm2_env.restart_time": 0,
                    "pm2_env.script": "./server.js",
                    "pm2_env.status": "online",
                    "pm2_env.unique_id": "858b1616-bfd7-41c0-8861-de5babcfe106",
                    "pm2_env.unstable_restarts": 0,
                    "pm2_env.version": "1.0.0",
                    "pm2_env.versioning.ahead": "false",
                    "pm2_env.versioning.branch": "master",
                    "pm2_env.versioning.branch_exists_on_remote": "true",
                    "pm2_env.versioning.comment": "update: Added query param to fetch mapped category in response\nfix: fallback envvar value\n",
                    "pm2_env.versioning.next_rev": "\u003cnil\u003e",
                    "pm2_env.versioning.prev_rev": "f195db41aec0592142ef478c424ec1722c7318a4",
                    "pm2_env.versioning.remote": "origin",
                    "pm2_env.versioning.repo_path": "/home/ubuntu/workspace/node-express-app",
                    "pm2_env.versioning.revision": "8d31b501b38229171be428db1dc7e2b412694116",
                    "pm2_env.versioning.type": "git",
                    "pm2_env.versioning.unstaged": "true",
                    "pm2_env.versioning.update_time": "2024-10-16T06:03:22.325Z",
                    "pm2_env.versioning.url": "git@github.com:zmrfzn/node-express-app.git",
                    "pm2_env.watch": "false"
                },
                {
                    "event_type": "flexStatusSample",
                    "flex.Hostname": "ip-172-31-30-74",
                    "flex.IntegrationVersion": "1.15.2",
                    "flex.counter.ConfigsProcessed": 1,
                    "flex.counter.EventCount": 2,
                    "flex.counter.EventDropCount": 0,
                    "flex.counter.PM2Sample": 2,
                    "flex.time.elapsedMs": 263,
                    "flex.time.endMs": 1730119876587,
                    "flex.time.startMs": 1730119876324
                }
            ],
            "inventory": {},
            "events": []
        }
    ]
}

Here’s the simplified data that we’re capturing with Flex from the PM2 processes after transformations with JQ:

       {
            "appName": "expressApp-otel",
            "hostId": "ec2-webserver",
            "integration_name": "com.newrelic.nri-flex",
            "integration_version": "1.15.2",
            "monit.cpu": 0,
            "monit.memory": 80068608,
            "pid": 1310,
            "pm2_env.created_at": 1728589676754,
            "pm2_env.error_file": "logs/error.log",
            "pm2_env.exit_code": 1,
            "pm2_env.node_version": "16.17.0",
            "pm2_env.out_file": "logs/app.log",
            "pm2_env.pm_uptime": 1729058602010,
            "pm2_env.restart_time": 0,
            "pm2_env.script": "./server.js",
            "pm2_env.status": "online",
            "pm2_env.unique_id": "83e7e3d5-17d7-41b0-87fe-5201148c826a",
            "pm2_env.unstable_restarts": 0,
            "pm2_env.version": "1.0.0",
            "pm2_env.versioning.ahead": "false",
            "pm2_env.versioning.branch": "otel",
            "pm2_env.versioning.branch_exists_on_remote": "true",
            "pm2_env.versioning.comment": "chore: update OTEL SDK packages to latest",
            "pm2_env.versioning.next_rev": "<nil>",
            "pm2_env.versioning.prev_rev": "f9fb795ec5ec07d24bd858b55287cbffda44b365",
            "pm2_env.versioning.remote": "origin",
            "pm2_env.versioning.repo_path": "/home/ubuntu/workspace/otel/node-express-app",
            "pm2_env.versioning.revision": "aad10ae5445469718cd2da5041d140e39be8ef78",
            "pm2_env.versioning.type": "git",
            "pm2_env.versioning.unstaged": "true",
            "pm2_env.versioning.update_time": "2024-10-16T06:03:22.319Z",
            "pm2_env.versioning.url": "git@github.com:zmrfzn/node-express-app.git",
            "pm2_env.watch": "false",
            "timestamp": 1729513381684
          }

Verification

Flex sends all processed data via the New Relic events API, which allows efficient handling of various types of event data. In this configuration, we’re naming our event PM2Sample, which helps clearly identify and differentiate it from other events in the system.

All the data associated with this event can be easily queried using New Relic Query Language (NRQL) on this table itself.

FROM PM2Sample SELECT * SINCE 10 MINUTES AGO LIMIT 5

Visualization

Once the data is accessible on the New Relic platform, you can easily query specific metrics relevant to your needs and create tailored visualizations. This allows you to analyze performance trends, monitor process health, and also gather versioning details for the individual applications currently running with PM2.

With customizable visualizations, you can present the data in a way that best suits your objectives and enhances your understanding of complex information. Additionally, these metrics can also be used to set up personalized alerts.

Let’s dive into the PM2Sample. Now we can effortlessly query the average CPU utilization from individual applications:

FROM PM2Sample select average(monit.cpu) as 'CPU Usage %' facet appName

You can also capture time series data, showcasing how memory consumption compares to CPU usage over time for all your applications under PM2, which are outside of your APM metrics.

FROM PM2Sample select average(monit.memory)/1048576 as 'Avg Memory M/b' , average(monit.cpu) as 'Avg CPU%' EXTRAPOLATE TIMESERIES

NRQL provides an easy way to query and visualize metrics, with powerful dashboard capabilities. Below is an example of a custom dashboard setup specifically designed for PM2 monitoring. It captures various metrics, including memory usage per application, CPU vs. memory for all active applications, and the latest app revision details of the active processes with PM2.

Import this dashboard using the JSON from this location: PM2_monit_dashboard. Make sure to replace all the placeholder account Ids (1234567) with your New Relic account ID before importing it.

Conclusion

PM2’s telemetry offers process-level insights, capturing essential metrics like CPU, memory, and application logs. Flex’s customizable integration with New Relic allows you to bring these data points into a single, unified view. This combination not only enhances visibility into application performance, but also simplifies root-cause analysis and proactive monitoring

What Next?

For more information, visit the following:

Observability as code for AI apps with New Relic and Pulumi

Harry Kimpel — Mon, 14 Oct 2024 18:30:45 +0000

To read this full article, click here.

AI applications are complex and distributed, making effective monitoring challenging. Combining the New Relic intelligent observability platform with Pulumi's infrastructure-as-code and secret management solutions allows for an end-to-end "observability as code" approach. This method enables teams to:

Define artificial intelligence (AI) and large language model (LLM) monitoring instrumentation along with cloud resources programmatically.
Securely manage API keys and cloud account credentials.
Automatically deploy New Relic instrumentation alongside AI applications and infrastructure.

Benefits include:

Consistent monitoring across environments
Version-controlled observability configuration
Easier detection of performance issues
Deeper insights into AI model behavior and resource usage

The observability-as-code approach helps developers maintain visibility into their AI applications as they scale and evolve.

What is Pulumi?

Pulumi provides a range of products and services for platform engineers and developers, including:

Pulumi infrastructure as code (IaC): An open-source tool for defining cloud infrastructure. It supports multiple programming languages. For example, you can use Python to declare AWS Fargate services, Pinecone indexes, and custom New Relic dashboards.
Pulumi Cloud: A hosted service that provides additional features on top of the open-source tool, such as state and secrets management, team collaboration, policy enforcement, and an AI-powered chat assistant, Pulumi Copilot.
Pulumi Environments, Secrets, and Configuration (ESC): This ensures the secure management of sensitive information necessary for observability. For example, you can manage New Relic, OpenAI, and Pinecone API keys and configure OpenID Connect (OIDC) in AWS. This service is also part of Pulumi Cloud.

Pulumi allows teams to version control their observability configurations and infrastructure definitions. This ensures consistency across environments and simplifies the correlation of application changes with monitoring updates and underlying infrastructure modifications.

How to achieve observability as code with New Relic and Pulumi

In this guide, you’ll add AI and LLM monitoring capabilities to an existing chat application by configuring the New Relic application performance monitoring (APM) agent, and by defining New Relic dashboards in Python using Pulumi.

The final version of the application and infrastructure referenced throughout the guide resides in the AI chat app public GitHub repository.

Before you start

Ensure you have the following:

A New Relic account and a valid New Relic license key
A Pulumi Cloud account
The Pulumi CLI installed locally

All the services used throughout this guide qualify under the respective free tiers.

Explore the OpenAI demo application

The OpenAI demo application used throughout this guide is written in Node.js for the backend and Python for the frontend. It interacts with OpenAI to generate various gameplays through generative conversational AI interactions. It uses the public OpenAI platform to call its API to access different LLMs like GPT-3.5 Turbo, GPT-4 Turbo, and GPT-4o.

Below is a screenshot of a "higher or lower" gameplay:

The demo simulates a retrieval-augmented generation (RAG) flow, which commonly looks up information that the AI either doesn't know or might hallucinate. The app stores a handful of common game names and instructions in a Pinecone vector database and then uses it as an embedding when calling OpenAI.

This application is configured to observe its performance, such as traces, metrics, and logs. It leverages New Relic's latest innovation in monitoring AI interactions, such as requests and responses. This capability ensures compliance, promotes quality, and observes your AI costs.

Run the app locally with Docker Compose

The easiest way to run the chat on your local machine is via Docker Compose. Inspect the docker-compose.yml file in the ./app folder and create the required .env file as shown. Then, in your terminal, run:

cd app 
docker compose up \-d –build

By default, the web service will run on http://localhost:8888/.

Try out the API endpoints

The API backend provides various endpoints that expose all of its AI functionality. The frontend leverages these endpoints to simulate a flow of activity for end users to select a game and initiate a game interaction, that is, play the game, with OpenAI.

Follow these steps to simulate a higher or lower gameplay:

Open the web service http://localhost:8888/.
Click the Get Games button. A list of games is displayed.
In the Input field, copy higher or lower.
To retrieve a game prompt for the next step, click Get Game Prompt.
To send the OpenAI request to interact with the game, click Submit Prompt.
Enter your first guess into the Insert Your Game Interaction textbox. You’ll get a message about whether your guess was correct when compared to the number the AI picked. Repeat this step until you have guessed the correct number.

Configure New Relic agents with AI

The chat application is configured to capture telemetry using the New Relic APM agent for API and web services. This agent also leverages New Relic's latest innovation in monitoring AI interactions, such as requests and responses. This capability ensures compliance, promotes quality, and observes AI costs.

Enable the New Relic AI monitoring capabilities through the New Relic APM agent configuration or via environment variables:

NEW_RELIC_AI_MONITORING_ENABLED = TRUE
NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED = 10000
NEW_RELIC_CUSTOM_INSIGHTS_EVENTS_MAX_SAMPLES_STORED = 100000

Before exploring the data streamed by the New Relic agents, you’ll use Pulumi to deploy the application to AWS and create custom dashboards. This will enable you to simulate global traffic interacting with the application, thus generating representative AI metrics to forecast performance and cost.

Manage your secrets with Pulumi ESC

While running everything locally is always a good first step in the software development lifecycle, moving to a cloud test environment and beyond involves ensuring .env files are securely available and all the application infrastructure dependencies are deployed and configured. The "Ops" side of DevOps comes into the picture, but it need not be a daunting task. You’ll leverage Pulumi ESC to manage the chat application's secrets.

Create a Pulumi ESC Environment

You'll create a Pulumi ESC environment to store all your .env secrets in Pulumi Cloud. This enables teams to share sensitive information with authorized accounts. Ensure that your New Relic license key, OpenAI token, and Pinecone API keys are handy.

In your terminal, run:

pulumi login
E=my-cool-chat-app-env
pulumi env init $E --non-interactive
pulumi env set  $E environmentVariables.NEW_RELIC_LICENSE_KEY 123ABC --secret
pulumi env set  $E environmentVariables.OPENAI_API_KEY 123ABC --secret
pulumi env set  $E environmentVariables.PINECONE_API_KEY 123ABC --secret

Load your .env file with the Pulumi CLI

Now that you’ve defined your ESC environment, you can consume it in several ways. For instance, you can populate our .env files by opening the environment using dotenv formatting:

cd ./app
pulumi env open $E --format dotenv > ./.env
docker compose up -d –build

The Pulumi commands may be scripted to run inside an Amazon EC2 instance or AWS Fargate. Next, you’ll define AWS resources using Pulumi IaC and Python so that you can run the application in AWS. To learn more, visit the Pulumi ESC documentation.

Generate infrastructure code with Pulumi Copilot

Nowadays, you don’t need to start from scratch when using infrastructure as code. Instead, you’ll use the power of generative AI to write Python code to declare all the cloud resources needed for our chat application. This entails declaring New Relic, AWS, and Pinecone resources.

Pulumi Copilot is a conversational chat interface integrated into Pulumi Cloud. It can assist with Pulumi IaC authoring and deployment. Let's have an intelligent conversation with Pulumi Copilot to help us start writing a Python-based Pulumi program that will also have access to the previously created ESC environment.

Prompt Pulumi Copilot with:

Can you help me create a new and empty Python Pulumi project called "my-cool-chat-app" with a new stack called dev? Add "my-cool-chat-app-provider-creds" to the imports in the dev stack

Declare New Relic AI LLM monitoring dashboards

A standard method for sharing dashboards is through the JSON copy and import feature. However, importing these through the console can result in reproducibility issues over time. For example, what happens when the dashboard JSON definition changes in an undesirable way? It becomes a challenge because there are no versioning details readily available.

Instead, using a declarative approach to "import" the JSON file unlocks several benefits. It allows for managing the dashboard's lifecycle (creation, deletion, updates) through code, thereby tracking changes over time. Also, it makes it easy to incorporate into deployment pipelines and share these across teams.

You have an AI/LLM monitoring dashboard JSON file and want to use it to create a new dashboard under our New Relic account. Let's continue our chat with Pulumi Copilot and prompt it to update the current solution:

Okay great! Can you update the Python code to deploy a New Relic dashboard based on an existing JSON file I will provide as input?

Declare a Pinecone index

A Pinecone index was needed beforehand to test the chat application locally. Let's ensure its existence before deploying the chat application to the cloud.

Let's ask Pulumi Copilot to define this resource on our behalf:

Thank you! I also need a serverless Pinecone index named "games" in the "default" namespace on AWS us-east-1 with 1536 dimensions. Can you generate the Python code to define this resource?

Declare an Amazon EC2 instance

To test the chat application in a cloud environment, you'll use an EC2 instance. Let's ask Pulumi Copilot to define all the AWS resources:

Perfect! I also want to deploy my chat application to an Amazon EC2 Linux instance. 
Create a VPC, security group, public subnet, and route table for the EC2 instance.
Ensure the security group allows inbound SSH traffic on port 22 from anywhere.
Ensure the EC2 instance is publicly accessible and runs a Docker Compose command to start the application.
Associate the EC2 instance with a public IP
Update the EC2 instance with a depends_on resource option for the route table association.

Deploy the application with Pulumi

You’ve asked Copilot to help with the Python infrastructure code, so it's time to deploy our application. In the chat window, expand the Pulumi Code drop-down. Click the Deploy with Pulumi button to create a new project.

Once you download the project, you'll add credentials, modify the code slightly, and deploy our application on AWS.

Click the Deploy with Pulumi button to create a new project. Then,
Choose the CLI Deployment deployment method and click Create Project.
Follow step 3 from the "Get started" steps in the next window to download the project onto your development environment.

Given that you already have a relatively small application in a GitHub repository, you’ll add a new empty folder at the root level named infra, where you'll unzip the contents of the Pulumi project. Compare your solution with the final version hosted on GitHub and fix any minor details Copilot may have overlooked.

Also, include the following changes from the final version shared:

Update the custom user_data script.
Update the dashboard.json to include your New Relic account id.
Optionally, include the Docker build code to build and push the images to Dockerhub.

To learn more, visit the Pulumi Copilot documentation.

In order for Pulumi to deploy all the declared resources, it needs access to your cloud accounts. These credentials will reside in a Pulumi ESC Environment named "my-cool-chat-app-provider-creds". Refer to the README to configure the Environment and set up the Python virtual environment before deploying everything via:

pulumi up --stack dev  --yes

It takes about a minute for all resources to be created. Once created, access the public URL displayed and run load tests.

Example partial output from the above command:

     Type                                Name                        Status              
 +   pulumi:pulumi:Stack                 my-cool-chat-app-dev-dev    created (57s)       
 +   ├─ newrelic:index:OneDashboardJson  my_cool_dashboard           created (2s)        
 +   ├─ pinecone:index:PineconeIndex     my_cool_index               created (7s)        
 +   ├─ docker-build:index:Image         ai-chat-demo-api            created (2s)        
 +   ├─ docker-build:index:Image         ai-chat-demo-web            created (3s)        
 +   ├─ aws:ec2:Vpc                      my_cool_vpc                 created (13s)       
 +   ├─ aws:ec2:Subnet                   my_cool_subnet              created (11s)       
 +   ├─ aws:ec2:SecurityGroup            my_cool_security_group      created (4s)        
 +   ├─ aws:ec2:InternetGateway          my_cool_igw                 created (1s)        
 +   ├─ aws:ec2:RouteTable               my_cool_route_table         created (2s)        
 +   ├─ aws:ec2:RouteTableAssociation    my-route-table-association  created (0.89s)     
 +   └─ aws:ec2:Instance                 my_cool_instance            created (24s)       

Outputs:
    url: "52.41.60.240"

Resources:
    + 12 created

Duration: 1m0s

Explore your New Relic AI LLM dashboards

To recap, the chat application is configured to observe its performance, such as traces, metrics, and logs, using the New Relic APM agent and the infrastructure agent. Now that we’ve simulated traffic, let's review the collected telemetry data in New Relic.

AI Response metrics

The AI Responses section will highlight key metrics when observing your AI/LLM applications. It includes data such as Total responses, Response time, Token usage per response, and Errors within your AI interactions. Time series graphs show you the same information with some more historical context.

The bottom part of that screen provides more insights into the requests and responses your end customers used to interact with the chat application.

AI Model comparison

Another very important aspect of New Relic AI monitoring is the Model Inventory section.

This view provides an intuitive overview of all your AI/LLM models being leveraged in our chat application. As you can see, we ran the same application with OpenAI models GPT-3.5 Turbo, GPT-4 Turbo, and GPT-4o. The AI model used is reflected in the chatModel variable for the API AI backend. This view shows you all the critical aspects of the performance, quality of responses, errors, and cost at a glance.

When combining the raw data from AI monitoring and custom lookup tables, New Relic also allows you to build custom dashboards (see Deploy the application with Pulumi for a reference to import custom dashboards). These custom dashboards can bring additional data, such as the actual cost (in $) for my OpenAI platform, and leverage the input and output tokens from our monitoring to calculate the total AI cost for running the chat application.

OpenAI custom dashboards

Next steps

In this guide, you explored an AI demo application powered by OpenAI and Pinecone. The application uses New Relic AI dashboards to monitor costs and other performance metrics. You used Pulimi Copilot to generate all the cloud components needed to run the chat application in AWS successfully while storing all sensitive information in Pulumi ESC.

Join us in the Observability as Code for AI Apps with New Relic and Pulumi virtual workshop, where you'll see the chat application, Pulumi, and New Relic in action.

New Relic Integrates its Observability Platform with NVIDIA NIM to Accelerate AI Adoption and ROI

samanthadondero — Mon, 24 Jun 2024 22:16:30 +0000

Hi, devs!

Today we're announcing that New Relic and NVIDIA released the first observability integration making it easy for companies to monitor the health and performance of their AI applications built with NVIDIA NIM.

Key features and use cases for AI monitoring include:

Full AI stack integration
Deep trace insights for every response
Model inventory
Deep GPU insights
Enhanced data security

➡️ Check it out

-Sam

Using .NET Aspire eShop application to collect all the telemetry

Harry Kimpel — Mon, 10 Jun 2024 08:15:37 +0000

To read this full article, click here.

Learn how to collect all the telemetry from the .NET Aspire eShop application and send it to an OpenTelemetry backend such as New Relic

.NET Aspire is the new kid on the block when it comes to an opinionated, cloud-ready stack for building observable, production-ready, distributed applications. Having a built-in dashboard for the monitoring data is nice during development. But how do you configure OpenTelemetry correctly to send it to an observability backend? This is what this blog post is all about. And you’ll also learn how to send custom attributes by leveraging OpenTelemetry SDKs.

.NET Aspire

.NET Aspire was first announced and introduced at .NET Conf 2023 Keynote. The challenges it tries to solve are:

Complex: Cloud computing is fundamentally hard.
Getting started: For new developers in this space, a first step into cloud native can be overwhelming.
Choices: Developers need to make a lot of choices.
Paved path: .NET did not have a golden paved path available for developers to build cloud-native applications.

This is exactly where .NET Aspire comes into play. It includes the following features as part of the stack:

Components: Curated suite of NuGet packages specifically selected to facilitate the integration of cloud-native applications with prominent services and platforms, including but not limited to Redis and PostgreSQL. Each component furnishes essential cloud-native functionalities through either automatic provisioning or standardized configuration patterns.

Developer Dashboard: Allows you to track closely various aspects of your application, including logs, traces, and environment configurations, all in real time. It’s purpose-built to enhance the local development experience, providing an insightful overview of your app’s state and structure.
Tooling/Orchestration: .NET Aspire includes project templates and tooling experiences for Visual Studio and the dotnet command-line interface (CLI) help you create and interact with .NET Aspire apps. It also provides features for running and connecting multi-project applications and their dependencies.

eShop demo application

A reference .NET application implementing an ecommerce website using a services-based architecture.

In the latest version of the application, the source code is already updated to include .NET Aspire as part of the project. You can install the latest .NET 8 SDK and clone the repository. Additionally, you can run the following commands to install the Aspire workload:

dotnet workload update
dotnet workload install aspire
dotnet restore eShop.Web.slnf

Once you have all the other prerequisites ready on your machine, you can run the application from your terminal with the following command:

dotnet run --project src/eShop.AppHost/eShop.AppHost.csproj

.NET Aspire developer dashboard

Once the application is up and running, go to the developer dashboard to identify the various resources that are part of the eShop application, including the endpoints and URL(s) to reach the running resources directly.

This dashboard also includes monitoring telemetry, including logs, traces, and metrics.

.NET Aspire orchestration

.NET Aspire provides APIs for expressing resources and dependencies within your distributed application.

Before continuing, consider some common terminology used in .NET Aspire:

App model: A collection of resources that make up your distributed application (DistributedApplication). For a more formal definition, see Define the app model.
App host/Orchestrator project: The .NET project that orchestrates the app model, named with the *.AppHost suffix (by convention).
Resource: A resource represents a part of an application whether it be a .NET project, container, or executable, or some other resource like a database, cache, or cloud service (such as a storage service).
Reference: A reference defines a connection between resources, expressed as a dependency. For more information, see Reference resources.

.NET Aspire empowers you to seamlessly build, provision, deploy, configure, test, run, and observe your cloud application. This is achieved through the utilization of an app model that outlines the resources in your app and their relationships.

Sending telemetry to an OpenTelemetry backend such as New Relic

Having a built-in dashboard for the monitoring data is nice during development. In this section I focus on how to configure OpenTelemetry correctly to send all telemetry into New Relic as my observability backend of choice.

For the scenario described in this article, I created my own fork of the official eShop application. Within this repository, you’ll be able to find the app host project that contains its main component.

Lines 17 through 26 define some basic configuration variables that you can provide using environment variables in your terminal.

NEW_RELIC_LICENSE_KEY: New Relic license key for the OpenTelemetry protocol (OTLP) API header value
NEW_RELIC_REGION: US or EU region configuration for your New Relic account

Based on the New Relic region configuration, the code will define the New Relic OTLP endpoint for OpenTelemetry and use it in the OTEL_EXPORTER_OTLP_ENDPOINT variable.

The rest of the app host project is already prepared to add an environment configuration for each of the projects that are part of the Aspire application. For example, here’s the configuration for the Identity.API project:

...
// Services
var identityApi = builder.AddProject<Projects.Identity_API>("identity-api")
    .WithReference(identityDb)
    .WithEnvironment("OTEL_EXPORTER_OTLP_ENDPOINT", OTEL_EXPORTER_OTLP_ENDPOINT)
    .WithEnvironment("OTEL_EXPORTER_OTLP_HEADERS", OTEL_EXPORTER_OTLP_HEADERS)
    .WithEnvironment("OTEL_SERVICE_NAME", "identity-api");
...

In this fork of the eShop application I’ve added some additional environment configuration. Each of the .WithEnvironment statements adds a necessary environment variable for the service:

OTEL_EXPORTER_OTLP_ENDPOINT: The OTLP endpoint for all the telemetry for this service; in our case, the New Relic OTLP endpoint.
OTEL_EXPORTER_OTLP_HEADERS: The API header value, which includes our New Relic license key (string OTEL_EXPORTER_OTLP_HEADERS = "api-key=" + NEW_RELIC_LICENSE_KEY;).
OTEL_SERVICE_NAME: The name of the service relevant to create a respective entity in New Relic.

The rest of the services are configured appropriately.

Once you’ve configured the environment variables in your terminal (that is, NEW_RELIC_LICENSE_KEY and NEW_RELIC_REGION), you can start the Aspire application with the following command:

dotnet run --project src/eShop.AppHost/eShop.AppHost.csproj

You can confirm whether everything is configured correctly by looking at the environment and clicking on the view icon for one of the projects:

The OTEL_EXPORTER_OTLP_ENDPOINT should point to the New Relic OTLP endpoint.

After a little while, you should be able to see data from your application visible in the APM & Services - OpenTelemetry section of New Relic:

You can then observe and analyze all your telemetry. For example, look at the New Relic Services map:

… or the distributed tracing view:

Happy observing!

Conclusion

Integrating OpenTelemetry with the .NET Aspire eShop application and New Relic allows you to leverage powerful telemetry tools to monitor and improve your application's performance. This setup not only provides valuable insights but also enhances your ability to diagnose issues quickly and efficiently. With the steps outlined in this guide, you're well on your way to building a more resilient and observant application. Start harnessing the full potential of your telemetry data today and keep your systems running smoothly!

Next steps

Explore more: Dive deeper into New Relic’s OpenTelemetry documentation to unlock advanced features.
Join the community: Engage with other developers on New Relic’s community forum.
Stay updated: Follow our blog for the latest tips, tutorials, and industry news.
Try New Relic for free: Sign up for a free New Relic account and start exploring how New Relic can enhance your application's telemetry today.
Experiment and iterate: Continuously monitor, analyze, and improve your telemetry setup for peak performance.

How to observe your Blazor WebAssembly application with OpenTelemetry and real user monitoring

Harry Kimpel — Mon, 10 Jun 2024 08:01:46 +0000

To read this full article, click here.

Observing WebAssembly applications presents unique challenges that stem from its design and execution environment. Unlike traditional web applications, where monitoring tools can hook directly into JavaScript and the Document Object Model (DOM), WebAssembly runs as binary code executed within the browser's sandbox. This layer of abstraction complicates direct introspection, as traditional monitoring tools are not designed to interact with the lower-level operations of WebAssembly. The Bytecode Alliance plays a crucial role here, promoting standards and tools that aim to enhance the security and usability of WebAssembly, including better support for observability. Moreover, the performance characteristics of WebAssembly, which can closely approach native speeds, demand monitoring solutions that are both highly efficient and minimally invasive to avoid impacting the user experience. This creates a complex scenario for developers who need detailed visibility into their applications' behavior without sacrificing performance.

Blazor WebAssembly: Leveraging .NET in the browser

.NET Blazor WebAssembly is a cutting-edge framework that allows developers to build interactive client-side web UIs using .NET rather than JavaScript. By compiling C# code into WebAssembly, Blazor WebAssembly empowers developers to leverage the full-stack capabilities of .NET, utilizing the same language and libraries on both the server and client sides. This unique approach streamlines the development process and enables rich, responsive user experiences with significant performance benefits.

With the release of .NET 8, Blazor WebAssembly has introduced new rendering modes that enhance flexibility and performance across diverse deployment scenarios. These modes include:

Static server rendering (also called static server-side rendering or static SSR) to generate static HTML on the server.
Interactive server rendering (also called interactive server-side rendering or interactive SSR) to generate interactive components with prerendering on the server.
Interactive WebAssembly rendering (also called client-side rendering or CSR, which is always assumed to be interactive) to generate interactive components on the client with prerendering on the server.
Interactive auto (automatic) rendering to initially use the server-side ASP.NET Core runtime for content rendering and interactivity. The .NET WebAssembly runtime on the client is used for subsequent rendering and interactivity after the Blazor bundle is downloaded and the WebAssembly runtime activates. Interactive auto rendering usually provides the fastest app startup experience.

The auto rendering mode in particular make Blazor WebAssembly an even more compelling choice for developers who are looking to build modern web applications using .NET technologies.

This blog post focuses specifically on Blazor WebAssembly and explores its capabilities and practical applications in modern web development.

Enhancing Blazor WebAssembly observability with OpenTelemetry in .NET

In this exploration of Blazor WebAssembly, we delve into how OpenTelemetry (sometimes referred to as OTel) can be integrated with .NET to provide comprehensive observability for these applications. OpenTelemetry, a set of APIs, libraries, agents, and instrumentation, allows developers to collect and export telemetry data such as traces, metrics, and logs to analyze the performance and health of applications. For .NET developers, the integration with OpenTelemetry is particularly seamless, as all telemetry for .NET is considered stable, ensuring reliability and robust support across various deployment scenarios.

Exploring a sample Blazor WebAssembly application

In this blog post, we'll be utilizing a sample application that embodies the principles of Blazor WebAssembly combined with OpenTelemetry. The application, which can be found in the GitHub repository, serves as an excellent example of a standalone Blazor WebAssembly application. This practical example will serve as the foundation for our discussion on implementing and observing OpenTelemetry in a .NET environment. By dissecting this application, we can better understand the interaction between Blazor’s client-side component as a Blazor WebAssembly application running in the browser and a Blazor WebAssembly backend application that the web frontend talks to.

Automated and manual instrumentation of the backend

When deploying OpenTelemetry in a Blazor WebAssembly application, automated instrumentation becomes a pivotal component, particularly when interfacing with the .NET backend. OpenTelemetry's .NET libraries offer out-of-the-box instrumentation for ASP.NET Core, which effortlessly captures telemetry data such as HTTP requests, database queries, and much more. This automated process simplifies the task of implementing comprehensive monitoring, as it requires minimal manual configuration and coding. Additionally, integrating OpenTelemetry into your project is as straightforward as adding the respective NuGet packages to your solution.

For developers working with Blazor WebAssembly, this means enhanced visibility into the backend operations that power their applications. Automated instrumentation ensures that all relevant data transactions between the client and server are meticulously monitored, providing insights into performance metrics and potential bottlenecks. By leveraging this feature, developers can focus more on building features and less on the intricacies of setting up and maintaining observability infrastructure, making it easier to deliver high-performance, reliable applications.

The project file for the .NET Blazor WebAssembly backend looks like this (you can find the full project file in the repository):

   <PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.8.0" />
   <PackageReference Include="OpenTelemetry.Instrumentation.EntityFrameworkCore" Version="1.0.0-beta.9" />
   <PackageReference Include="OpenTelemetry.Instrumentation.Runtime" Version="1.8.0" />
   <PackageReference Include="OpenTelemetry" Version="1.8.0" />
   <PackageReference Include="OpenTelemetry.AutoInstrumentation.Runtime.Native" Version="1.5.0" />
   <PackageReference Include="OpenTelemetry.Exporter.Console" Version="1.8.0" />
   <PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.8.0" />
   <PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.8.1" />
   <PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.8.1" />

When running the Blazor backend with automated OpenTelemetry instrumentation and exporting the telemetry to the console, we can easily see the traces, metrics, and logs as part of the console output (here in VS Code terminal).

But looking at telemetry such as traces, metrics, and logs in the console output is not really helpful. So, ideally, we want to export that data to an OpenTelemetry telemetry backend. I am of course using New Relic.

In a typical OpenTelemetry fashion, I only need to provide a few environment variables when executing the application. I highlighted the most important ones in the below screenshot. You can find the full run script in the repository.

Once the application is up and running, you find the application entity in APM & Services under the OpenTelemetry section. The screenshot below shows the Summary view.

Distributed Tracing view:

View of a single trace (I highlighted the backend span to /roles endpoint):

When you look at the above span to the BlazorWASMBackend service GET /roles, you’ll notice that the total time spent in the backend span is 4.61s. We cannot really tell where exactly the time is spent. Out of the box, when using auto instrumentation, I don’t get further detail into what is actually happening in that method.

In order for me to provide more details into that method, I’ll need to add some manual instrumentation into my source code by leveraging the OpenTelemetry SDK for .NET.

In this case, I changed the original code of the

app.MapGet("/roles", …

method from this original implementation:

           // Instantiate random number generator using system-supplied value as seed.
           var rand = new Random();
           int waitTime = rand.Next(500, 5000);

           // do some heavy lifting work
           Thread.Sleep(waitTime);

and added in some .NET-specific implementation of a custom OpenTelemetry span:

           // Instantiate random number generator using system-supplied value as seed.
           var rand = new Random();
           int waitTime = rand.Next(500, 5000);


           using (var sleepActivity = DiagnosticsConfig.ActivitySource.StartActivity("RolesHeavyLiftingSleep"))
           {
               // do some heavy lifting work
               Thread.Sleep(waitTime);


               string waitMsg = string.Format(@"ChildActivty simulated wait ({0}ms)", waitTime);
               sleepActivity?.SetTag("simulatedWaitMsg", waitMsg);
               sleepActivity?.SetTag("simulatedWaitTimeMs", waitTime);
               DiagnosticsConfig.logger.LogInformation(eventId: 123, waitMsg);
           }

The using-block actually triggers a new span to be created with the name RolesHeavyLiftingSleep. I save the activity into the sleepActivity variable. You’ll further notice that I’m also adding some custom tags to that same activity by calling sleepActivity?.SetTag().

We can see in the screenshot below what the result of that change looks like if we restart our application.

The trace in the screenshot above allows me to drill deeper into the backend span by enabling the in-process spans. In here, we can see that there’s a RolesParentActivity, followed by a RolesChildActivity, and finally our RolesHeavyLiftingSleep span from our manual instrumentation. This screenshot also shows a section of the attributes that are associated with that span. As you can see, the custom tags simulatedWaitTimeMs and simulatedWaitMsg are visible as well. These custom tags are potentially helpful when doing some root cause analysis or troubleshooting.

Instrumentation of the frontend

Now that we’ve seen how the backend can be instrumented with OpenTelemetry, let’s focus on the frontend now, that is, the Blazor WebAssembly component.

When we try to instrument the WebAssembly component with auto instrumentation for OpenTelemetry, the C# project file looks similar to the backend. This is actually the benefit of Blazow WebAssembly—that we can use C# not only for the backend, but also for the WebAssembly frontend.

Let’s configure the console exporter again for our OpenTelemetry telemetry. Unsurprisingly, the output will be visible in the respective developer tools of our web browser.

The screenshot above shows the actual UI of the Blazor WebAssembly frontend in the upper section of the screenshot. If the user of the application clicks the Click me button, a trace is generated and output in the browsers console view.

Again, this is adequate for testing, but in order to actually leverage the telemetry in a meaningful way, we need to export all telemetry to an OpenTelemetry backend, in my case New Relic. For this to happen, we need to define an OpenTelemetry protocol (OTLP) exporter and configure the OTLP endpoint as well as the OTLP header information similar to what we’ve seen for the backend.

But wait; as soon as we implement these changes and rerun the application, an exception is generated.

The exception is Operation is not supported on this platform. If we think about it, it does make sense since we’re trying to make a HTTP request from our WebAssembly component to an external endpoint. However, since WebAssembly by itself doesn't have any access to its host environment, it doesn't have any built-in input/output (I/O) capabilities. For security reasons, it’s not possible to make HTTP requests from within a WebAssembly component.

So, if plain OpenTelemetry instrumentation isn’t possible, what is it that we can do for the frontend then?

As part of OpenTelemetry, the community is also working on some real user monitoring capabilities.

However, this is very early stages and not fully spec’d out. The current draft is also only focusing on Node.js and TypeScript. In the future this may be an option that could be leveraged for the frontend component.

One way to get details of the WebAssembly component is to leverage real user monitoring capabilities via the New Relic browser.

After getting the JavaScript snippet from a newly created New Relic browser application copied into the Blazor WebAssembly project (this is the place to put it), we can already see some high-level telemetry from the frontend.

Distributed tracing view:

AJAX requests:

What else can we do with the frontend? Some parts of the frontend will have interactions with the backend (like login and logout authentication). Other parts just execute code within the WebAssembly component. An example of this is the Counter section.

As you can see in the page source of that page, there’s no actual HTML representation.

Let’s see what we can do there.

One way is to invoke JavaScript functions from the actual .NET code. The following screenshot shows how this can be achieved (here is the link to the respective file in the repository).

The New Relic browser API allows users to add some custom page actions. This way we can observe all clicks on the counter and also capture the current value of the counter as a custom attribute.

Once we’ve implemented this and deployed a new release of the application, we can for example show this data on a custom dashboard to see the distribution of the actual counter values across all users of the application.

Furthermore, New Relic quickstarts, also known as Instant Observability, contain a sample dashboard that you can deploy into your account in order to see some additional Blazor WebAssembly specific telemetry in a pre-built dashboard.

Next steps

Observing Blazor WebAssembly applications is not quite straightforward as of today. There are many moving parts that the industry and the respective open-source communities are working on. This applies to the WebAssembly component model, as well as the OpenTelemetry implementation of real user monitoring. I think these challenges will soon be solved and there will be easier ways to get started.

Until then, in this blog post I showed a way to get some insights into your Blazor WebAssembly backend and frontend components.

New Relic provides a free account that you can use to get started with your journey on observing Blazor WebAssembly applications.

New Relic AI monitoring, the industry’s first APM for AI, is here!

samanthadondero — Tue, 23 Apr 2024 22:28:52 +0000

Hi, devs!

Want to know how you can streamline troubleshooting and optimize for performance, quality, and cost all in one?

New Relic AI monitoring provides engineers and developers unprecedented visibility across your AI stack, making it easier to troubleshoot and optimize your AI applications for performance and more!

Key features and benefits include:
Quick and easy setup via existing APM agents
Visibility across the entire AI app stack
Deep trace insights with end-user feedback for every response
Compare performance and costs across models in production
Enhanced data privacy and security

➡️ Get started now

-Sam

Guide: How to route Docker logs correctly in New Relic

Harry Kimpel — Fri, 12 Apr 2024 05:36:57 +0000

To read this full article, click here.

Streamlining Container Log Management for Clarity and Control

Hello, New Relic aficionados! Picture this: you're at a bustling local user group meetup, exchanging ideas and sharing tech stories. Amidst the animated discussions and clinking coffee cups, a fellow developer—let’s call him Alex—shares a frustrating puzzle. Alex’s Docker Compose applications are acting like rebellious teenagers, sending their logs to the New Relic Host UI instead of their designated New Relic Container UI. As you dive deeper into the problem, a light bulb goes off. This isn't just Alex's struggle; it’s a common snag affecting many of us in the Docker and New Relic community.

Why do these logs prefer the scenic route, and how can we guide them to their proper home? Inspired by this real-life challenge, I embarked on a quest to demystify the log misdirection issue and share a roadmap to log management nirvana with New Relic. So, grab your digital compasses, dear readers—it's time to navigate through the foggy waters of Docker logging and ensure your data logs exactly where it should.

Understanding the core issue: Where do my container logs end up?

So, what's the fuss about where logs end up anyway? Let's break it down. When you're running applications in containers, especially when using Docker, logging isn't just about keeping a record; it's about clarity and context. The New Relic infrastructure agent (along with the New Relic integration for Docker) is designed to be thorough—it dutifully collects logs from the host and any containers running on it. But here’s the snag: instead of neatly categorizing container logs under each container, all logs get lumped together. Your container logs are showing up right alongside host/server logs in the New Relic infrastructure Hosts UI.

And the Logs section of your Container UI does not show any logs:

Why does this matter? Imagine trying to find a specific conversation in a bustling, crowded room. Every discussion, whether it’s crucial or trivial, merges into one overwhelming cacophony. That's your current logging scenario—container logs are getting lost in the noise of the host logs, making it challenging to pinpoint issues or understand the behavior of specific containers.

This misassignment doesn’t just clutter your view; it complicates monitoring and troubleshooting by obscuring the boundaries between container-specific operations and overall host activity. You need to see your container logs isolated from host logs to quickly diagnose issues, scale effectively, and understand exactly how your containers are performing in the wild.

In the following sections, we'll explore why this log misplacement occurs and how you can reroute your logs to their correct destinations in New Relic, ensuring that your monitoring setup is as sharp and efficient as your development environment.

Configuring your environment for precise log routing

Now that we understand the issue at hand, let's roll up our sleeves and tackle the solution. Organizing your logs with New Relic starts with a few key adjustments in your environment. Here’s a simple guide to ensure your container logs aren’t just collected but correctly associated with their respective container entities in New Relic Logs.

Step 1: Adjust your logging configuration

Chances are, this step might already be in place if you've been monitoring with New Relic. Your goal here is to ensure that the logs from each container are being captured effectively. This involves tweaking your logging configurations to include detailed information about each container's operations. If this isn't set up yet, here's what you typically need to modify in your environment settings to start capturing those logs.

Here’s the snippet that you can copy and use in your logging.yml:

- name: containers
    file: /var/lib/docker/containers/*/*.log

Step 2: Tagging containers in Docker

Next, you’ll need to make your containers recognizable by tags when running your containers manually using ‘docker run’ command or within your Docker Compose configuration file. Adding the below tag makes this happen:

Docker run command example

docker run --log-opt tag="{{.Name}}" -d log-generator

Docker Compose example in docker-compose.yml

Here’s the snippet that you can copy and use in your docker-compose.yml:

version: '3.9'
x-default-logging: &logging
  driver: "json-file"
  options:
    max-size: "5m"
    max-file: "2"
    tag: "{{.Name}}"

This configuration ensures that each log entry from your containers includes the container's name as a tag, making it easier to track in the logs collected by New Relic.

Step 3: Set up a log parsing rule in New Relic Logs

Once you start seeing the container tags coming through in your New Relic environment, it’s time to refine how these logs are parsed and displayed. Setting up a log parsing rule helps in categorizing and querying logs based on specific attributes.

Here’s how to configure it:

Name: container name
Field to parse: attrs.tag
Filter logs based on New Relic Query Language (NRQL): attrs.tag is not null
Parsing rule: %{NOTSPACE:containerName}

This parsing rule will extract the container name from the attrs.tag field of each log entry and add an additional attribute named containerName, enabling you to filter and analyze logs by specific containers.

Conclusion

With these three steps, your container logs will not only be more organized but also more insightful. By ensuring that each log entry is correctly tagged and parsed, they'll directly feed into New Relic's powerful logging tools, allowing you to monitor and troubleshoot with unmatched precision. This setup not only enhances your ability to respond to issues swiftly but also empowers your team with data-driven insights, ensuring your applications run smoothly and efficiently.

As we wrap up our guide on streamlining Docker logs in New Relic, remember that effective log management is just one piece of the observability puzzle. To further illustrate the power of integrated monitoring tools, I recently contributed to enhancing the OpenTelemetry demo application. My pull request (PR #1495) has been accepted and merged, introducing a new tagging feature that you'll find particularly useful when running the demo with Docker Compose. This addition helps ensure that container logs are easily distinguishable and accurately attributed, enhancing your ability to monitor and troubleshoot effectively. Check out the changes and explore how they can benefit your setup here.

In addition to contributing to the OpenTelemetry demo application, I've also updated the respective sections of the New Relic documentation to reflect these improvements in log management. This update ensures that the strategies and technical details we've discussed are not only tested but also officially integrated into our guidance, making it easier for you to implement and benefit from these changes. You can view these updates (soon) to enhance your understanding and application of these practices, ensuring you get the most out of your New Relic tools.

Next steps

Congratulations on configuring your Docker environment for optimal log management! But the journey doesn’t stop here. Dive deeper into the possibilities:

Experiment and refine: Adjust the logging levels and parsing rules based on the specific needs of your environment. Each application may have unique insights to offer.
Monitor the impact: Keep an eye on how these changes enhance your monitoring capabilities. Look for improvements in troubleshooting and system performance.
Share your insights: Got a handle on things? Don’t keep it to yourself. Share your success stories and challenges in the comments below or on social media. Your experiences could shine a light for fellow developers navigating similar challenges.
Engage with the community: Join discussions on the New Relic Explorers Hub to connect with other users and exchange tips and tricks. Your feedback not only contributes to community growth but also helps us improve and evolve our solutions.

Ready to elevate your log management game? Start tweaking, sharing, and engaging today. Let’s harness the full potential of precise log data together!

New Instant Observability integrations for monitoring API, network, application, and streaming performance

Louis Leung — Sun, 31 Mar 2024 22:01:59 +0000

To read this full New Relic blog, click here.

Engineers rely on many tools to monitor the health of their systems, making it difficult to gain end-to-end observability without having to toggle between multiple solutions. To help combat this issue of tool sprawl and data silos, we partner with leading technology companies to build integrations to make it easy to visualize, monitor, and act on all your data in a single observability platform.

You can find all of our partner integrations in New Relic Instant Observability (I/O), an open ecosystem of more than 450 free, prebuilt quickstarts that help you start monitoring your system in minutes. These quickstarts bundle necessary building blocks for instrumenting, monitoring, and acting on signals from your telemetry data, wherever it comes from.

New partner integrations

The latest cohort of partners contributing to New Relic Instant Observability span across customer experience monitoring, web performance, and API management.

This month, we’re announcing new integrations and quickstarts with the following partners:

Datazoom
Glassbox
Cloudflare
Netlify
Postman

Read on to learn what you can do with these new quickstarts.

Cloudflare Network Logs

Cloudflare is an industry-leading global network designed to make everything you connect to the Internet secure, private, fast, and reliable. Use Cloudflare to protect and accelerate external, public-facing web properties, secure your internal operations on one global network, and build new applications on Cloudflare's serverless platform. Internet properties powered by Cloudflare have all web traffic routed through Cloudflare's intelligent global network.

The new Cloudflare Logpush integration sends Cloudflare data directly into New Relic, resulting in faster log delivery and eliminating cloud storage middleware costs. With the Cloudflare Network Logs quickstart, you can monitor and analyze web traffic metrics from Cloudflare Logpush on a New Relic dashboard. You get an overview of important logs and metrics from your websites and applications.

Learn more about how to send log insights faster and cheaper through the Cloudflare integration.

Netlify Logs

Platform developers love Netlify for building high-performance, dynamic web sites, e-commerce stores, and applications. As a pioneer of the Jamstack movement, Netlify brings together modern web frameworks, serverless functions, and edge computing into one platform to deliver unmatched experiences for your application users.

With the Netlify Logs quickstart, you can explore and visualize data from traffic and function logs provided by Netlify log drains. It allows you to parse, view, and filter traffic logs and function logs generated by your Netlify workloads for in-depth analysis, performance monitoring, troubleshooting, and alerting within New Relic.

Learn more about exporting traffic and function logs from Netlify to New Relic by reading the Better monitoring for your Netlify sites blog post, or watch this tutorial:

Postman

Postman helps more than 17 million developers collaborate and create better APIs. The Postman quickstart provides Postman monitoring data to New Relic, so that DevOps, APIOps, and ITOps engineers can get instant observability into critical metrics such as latency, request counts, and error rates to collaborate better. The integration also ingests data from New Relic into Postman to bring observability data to API producers, testers, and consumers.

Learn how to send real-time API metrics from Postman to New Relic in the API monitoring with Postman integration blog post, or watch this tutorial:

Datazoom

Datazoom is an enterprise video data platform. The software solution captures, standardizes, enriches, and routes data from various points across an end-to-end video workflow. Through a variety of real-time data collection and routing services, Datazoom’s platform provides flexibility and transparency in data collection so that teams can make operations, engineering, product and business decisions with confidence. Companies can drive revenue with streaming video by using Datazoom to democratize insight, increase efficiencies, and deliver captivating end-user experiences.

The Datazoom quickstart provides a fast and easy launching point into video metrics built on top of New Relic dashboards, so you can gain insights about your viewers, content, ads, and your platform's performance. You can customize the dashboard to use only metrics that fit your goals, edit metric calculations, and tailor them to your needs.

Learn more about the Datazoom integration at Get real-time visibility into your streaming video architecture and performance.

Glassbox

Glassbox empowers organizations to create frictionless digital journeys for their users. The Glassbox digital experience analytics and session replay platform work in real time across mobile apps and websites to increase user loyalty and accelerate growth. Through AI-driven visualization and analytics tools, Glassbox helps teams to prioritize customer experience and digital product enhancements from a single collaborative system.

The Glassbox quickstart helps you understand the impact of application performance on your users’ digital experience. Gain deeper contextual insights by combining the data capture and session replay capabilities of Glassbox with New Relic. Get a view of behavioral insights and KPIs inside a pre-built New Relic dashboard, which links directly to a session replay in Glassbox, so you can find the root cause of the digital issue and fix performance issues faster.

To read this full New Relic blog, click here.

Get your insights in minutes

Louis Leung — Sun, 31 Mar 2024 21:40:18 +0000

To read this full New Relic blog, click here.

At New Relic, we are committed to making observability a daily best practice for every engineer by investing heavily in the global open source community. In the last 12 months alone, we open sourced more than 10 years of R&D around agents, we standardized on OpenTelemetry, and we contributed Pixie to the Cloud Native Computing Foundation. New Relic I/O is a continuation of this strategy to dramatically reduce the barrier for engineers to embrace observability. Anyone can contribute data sources and share alert and dashboard configurations. Ultimately, we created New Relic I/O to make it easier for engineers to leverage community expertise to get more value out of their data, instantly.

The democratization of observability

How do you know that you are properly monitoring your LAMP stack, getting the right visibility into the performance of Gatsby sites, or debugging Kafka clusters with proven best practices? Today’s distributed environments are complex, and most engineers aren’t observability experts. Unless you’ve done it before, it’s difficult and time consuming to figure out how to instrument your distributed tech stack, capture the right data points with the right detail, and build dashboards from scratch to monitor your telemetry data.

According to New Relic’s 2021 Observability Forecast, while most IT decision makers are familiar with observability, there’s a huge gap in the practice: only 26% of respondents have a mature observability practice, and the most commonly cited barriers to observability success are lack of resources (38%) and skill gaps (29%).

What if there was an easier way to share these observability superpowers with all software engineers? And to get started quickly?

A single ecosystem for integrations, applications, and quickstarts

Enter New Relic I/O, an ever-expanding, open knowledge base of configurations and resources that taps into the collective experience of the world’s observability experts to help you unlock the value of your data faster. You can choose from hundreds of quickstarts (including LAMP, Gatsby, and Kafka) that bundle the necessary building blocks for instrumenting, monitoring, and acting on signals from your technology stack—and install them in a click. We’ve also built quickstarts for hundreds of end-to-end integrations for popular cloud services, tools, and open standards that include guided installation experiences as well as relevant dashboards and alerts. No matter which technologies you rely on, you can get observability coverage in minutes instead of days—or weeks.

Within New Relic Instant Observability, current New Relic One users can extend the platform with publicly available apps or any custom apps your team builds.

If you haven't used New Relic before, you can browse the catalog of available quickstarts in our public New Relic I/O catalog and get started with a free account in minutes.

How to install your first quickstart

Getting started with observability has never been easier. Before you begin, if you haven't used New Relic before, sign up for a free New Relic account (or log in to your existing account).

In New Relic One, to see the catalog, click Instant Observability in the top navigation. You can search, filter by contents, or select a category, such as Kubernetes or APM.

Then select a quickstart to learn more about it:

After you select a quickstart, you can see what’s included in the quickstart details. See a description of the pack, screenshots, and information on the included resources. Click Install this quickstart to get started.

Follow the instructions and install the necessary instrumentation to get the data used in the quickstart:

After you complete the installation process, click See your data:

Enjoy the dashboards, alerts, and insights:

Voila! You’re on the path to becoming an observability expert. Yes, it’s really as simple as that.

Partners in instant observability

We are proud to launch New Relic Instant Observability with pre-built quickstarts from six leading enterprise software partners. We have partnered closely with them to create quickstarts that help you extend your New Relic One experience:

Kentik is the network observability company. The Kentik quickstarts help network and development teams quickly identify and troubleshoot application performance issues correlated with network traffic performance and health data.
Fastly is an edge cloud platform that enables its customers to create great digital experiences quickly, securely, and reliably. With the Fastly CDN quickstart, you can monitor key metrics from Fastly’s content delivery network to improve service reliability and ensure great online experiences for end users.
Lacework is a data-driven security platform for the cloud that can collect, analyze, and accurately correlate data across an organization’s Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and Kubernetes environments, and narrow it down to the handful of security events that matter. The Lacework quickstart bridges the gap between observability and security teams, and integrates with New Relic’s database to surface security events and alerts directly in New Relic One.
Cribl is the observability pipeline company that lets customers parse and route any type of data. The Cribl quickstart allows you to get immediate visibility into your entire environment right from New Relic One without the need to create your own dashboards and alerts—simplifying your workflows and reducing time to value.
Trend Micro is a global cyber security leader. The Trend Micro Cloud One quickstart ingests cloud security posture management (CSPM) data from Conformity into New Relic One to contextualize and correlate it with workload telemetry data, delivering AI-powered visualizations and quick insights. This allows security and cloud teams to immediately take action in improving their security and compliance postures.
Gigamon is a hybrid-cloud visibility and analytics platform that provides access to—and extracts intelligence from—all network traffic. The Gigamon quickstart delivers advanced security capabilities that offer network detection and response to advanced threats, including shadow IT activities, crypto-mining and torrent activities, SSL cipher versions, and expiration dates across both managed and unmanaged hosts, such as IoT/OT and containers.

To read this full New Relic blog, click here.