Client-Side Logging with LogDNA

4 MIN READ
MIN READ

Update: On May 6, 2021 LogDNA introduced a new Browser Logger feature so that frontend developers can easily ingest browser logs, collect the diagnostic data that they need to understand when and why the user experience is degraded, and view browser data in context with other services (both on the client and server side). Learn more in this blog post: now.logdna.com/browserlogger.

Logging is an essential part of application development, monitoring, and debugging. There are countless libraries, frameworks, and services for logging backend and server-based applications. But for client-side applications, especially JavaScript-based web applications, it’s a different story. As we see increasingly complex code running on end user devices, the need to log these applications is also becoming increasingly important.

With version 3.0.1 of the LogDNA Node.js library, you can now use LogDNA’s Node.js library to log your client-side JavaScript applications to LogDNA. The library sends logs directly from your end users to LogDNA’s ingestion servers, letting you collect vital operational and debugging information without having to print logs to the console. The library offers a complete feature set including multiple log levels, customizable metadata, and the ability to add tags.

In this article, we will show you how to add client-side logging to your JavaScript applications and how it will benefit you and your team.

Adding Client-Side Logging to Your App

The LogDNA Node.js library supports Browserify and Webpack - utilities that automatically bundles JavaScript files along with any modules that they reference. You can use the require method to reference the LogDNA library from any JavaScript file, and Browserify will compile the library along with its required modules. You can then deploy the compiled file with your website as you would a normal JavaScript file.

With Browserify installed, follow the setup instructions on the Node.js agent page to initialize and configure the LogDNA agent. When declaring Logger.createLogger(), replace “API KEY HERE” with your LogDNA ingestion key. We recommend creating a new API key specifically for this use case.

const Logger = require('logdna');
const logger = Logger.createLogger('API KEY HERE', {
   hostname: 'client-device',
   app: 'my-client-side-app',
   index_meta: true
});

To avoid hard-coding your API key into your source code (which you should never do!), you can use a library such as envify to replace the API key string with an environment variable. Pass in your API key when calling Browserify, and envify will automatically insert it into the final bundle.

For example, the following code snippet replaces the hard-coded API key with the value stored in the LOGDNA_API_KEY environment variable:

const logger = Logger.createLogger(process.env.LOGDNA_API_KEY, {

   …


});

The following command calls Browserify and packages our source code file (“logdna.js”) into a bundle named “bundle.js”, replacing process.env.LOGDNA_API_KEY with our actual API key:

$ browserify logdna.js -t [ envify --LOGDNA_API_KEY <your actual="" api="" key=""> ] > bundle.js</your>

Now, you can include the newly created “bundle.js” file in your web application:

<script src="bundle.js" type="application/javascript"></script>

Pro Tip to Avoid CORS Issues

Before running the script, you will need to whitelist your domain in the LogDNA web app. Open the LogDNA web app and navigate to Settings > Organization > Whitelist Domains. Enter the domain(s) that you are deploying the script to. For example, if you are hosting a website at mydomain.com, you would add the domain as shown in the following screenshot. It may take a few minutes for your changes to take effect.

Next, let’s look at some use cases where client-side logging is helpful in combination with the server-side logging you do today.

Use Case #1: Collecting Diagnostic Data

Modern websites run full-blown applications in the browser, and like any application, these generate useful diagnostic and debugging data. However, this data is often stored on the user’s device, making it difficult to retrieve. Collecting this data typically requires using a separate solution that simulates real user behavior, or by asking users to report this data themselves.

A better way to handle this is to automatically log certain events such as errors. This immediately notifies you when a user experiences an error, and gives you the opportunity to collect relevant environmental data. For example, if your application throws an exception, you can log the full error message and stack trace directly to LogDNA.

If you have multiple deployments with different user bases—such as production, beta, and testing—you can even use tags feature to separate logs by deployment. This lets you, collect diagnostic data in your pre-release builds separately from your production builds, allowing you to troubleshoot and fix problems faster.

Use Case #2: Handling with High-Volumes of Client Log Data

In a typical client-server infrastructure, logs generated by the client are sent back to the server or simply ignored. While sending this data to your servers is helpful for collection and consolidation, it can add a significant amount of load. For high-traffic websites, this can add gigabytes or terabytes of data each day that your infrastructure will need to handle.

Client-side logging lets you bypass logging to your servers and instead log directly to LogDNA. Since LogDNA automatically scales to meet demand, this means you can collect more logs faster, and leave your backend servers to host your application.

Use Case #3: When Your Servers Fail

For any number of reasons, your users may lose access to your backend server. This might be due to an application crash, a network routing error, a new firewall policy, etc. Any of these incidents will prevent you from receiving important information about why your users lost connection. Sending your users’ logs to LogDNA provides an alternate means of collecting data in case your backend servers become unreachable.

This data could also offer insights that you can’t find in your server logs, such as the user’s browser version and session identifier.

Next Steps

With more and more applications moving to browsers and mobile devices, client-side logging is becoming more and more important as a tool for developers. LogDNA makes it easy to deploy a complete client-side logging solution with just a bit of JavaScript and single command.

We would love to hear how you'll be using LogDNA with client side logging.

To get started, check out the client side instructions for the LogDNA Node.js agent. To learn more about using the library and Node.js logging in general, check out our guide to logging Node.js applications the right way. And if you have any questions, please contact us.

Table of Contents

    Share Article

    RSS Feed

    Next blog post
    You're viewing our latest blog post.
    Previous blog post
    You're viewing our oldest blog post.
    The Observability Stack is Collapsing: Why Context-First Data is the Only Path to AI-Powered Root Cause Analysis
    Mezmo + Catchpoint deliver observability SREs can rely on
    Mezmo’s AI-powered Site Reliability Engineering (SRE) agent for Root Cause Analysis (RCA)
    What is Active Telemetry
    Launching an agentic SRE for root cause analysis
    Paving the way for a new era: Mezmo's Active Telemetry
    The Answer to SRE Agent Failures: Context Engineering
    Empowering an MCP server with a telemetry pipeline
    The Debugging Bottleneck: A Manual Log-Sifting Expedition
    The Smartest Member of Your Developer Ecosystem: Introducing the Mezmo MCP Server
    Your New AI Assistant for a Smarter Workflow
    The Observability Problem Isn't Data Volume Anymore—It's Context
    Beyond the Pipeline: Data Isn't Oil, It's Power.
    The Platform Engineer's Playbook: Mastering OpenTelemetry & Compliance with Mezmo and Dynatrace
    From Alert to Answer in Seconds: Accelerating Incident Response in Dynatrace
    Taming Your Dynatrace Bill: How to Cut Observability Costs, Not Visibility
    Architecting for Value: A Playbook for Sustainable Observability
    How to Cut Observability Costs with Synthetic Monitoring and Responsive Pipelines
    Unlock Deeper Insights: Introducing GitLab Event Integration with Mezmo
    Introducing the New Mezmo Product Homepage
    The Inconvenient Truth About AI Ethics in Observability
    Observability's Moneyball Moment: How AI Is Changing the Game (Not Ending It)
    Do you Grok It?
    Top Five Reasons Telemetry Pipelines Should Be on Every Engineer’s Radar
    Is It a Cup or a Pot? Helping You Pinpoint the Problem—and Sleep Through the Night
    Smarter Telemetry Pipelines: The Key to Cutting Datadog Costs and Observability Chaos
    Why Datadog Falls Short for Log Management and What to Do Instead
    Telemetry for Modern Apps: Reducing MTTR with Smarter Signals
    Transforming Observability: Simpler, Smarter, and More Affordable Data Control
    Datadog: The Good, The Bad, The Costly
    Mezmo Recognized with 25 G2 Awards for Spring 2025
    Reducing Telemetry Toil with Rapid Pipelining
    Cut Costs, Not Insights:   A Practical Guide to Telemetry Data Optimization
    Webinar Recap: Telemetry Pipeline 101
    Petabyte Scale, Gigabyte Costs: Mezmo’s Evolution from ElasticSearch to Quickwit
    2024 Recap - Highlights of Mezmo’s product enhancements
    My Favorite Observability and DevOps Articles of 2024
    AWS re:Invent ‘24: Generative AI Observability, Platform Engineering, and 99.9995% Availability
    From Gartner IOCS 2024 Conference: AI, Observability Data, and Telemetry Pipelines
    Our team’s learnings from Kubecon: Use Exemplars, Configuring OTel, and OTTL cookbook
    How Mezmo Uses a Telemetry Pipeline to Handle Metrics, Part II
    Webinar Recap: 2024 DORA Report: Accelerate State of DevOps
    Kubecon ‘24 recap: Patent Trolls, OTel Lessons at Scale, and Principle Platform Abstractions
    Announcing Mezmo Flow: Build a Telemetry Pipeline in 15 minutes
    Key Takeaways from the 2024 DORA Report
    Webinar Recap | Telemetry Data Management: Tales from the Trenches
    What are SLOs/SLIs/SLAs?
    Webinar Recap | Next Gen Log Management: Maximize Log Value with Telemetry Pipelines
    Creating In-Stream Alerts for Telemetry Data
    Creating Re-Usable Components for Telemetry Pipelines
    Optimizing Data for Service Management Objective Monitoring
    More Value From Your Logs: Next Generation Log Management from Mezmo
    A Day in the Life of a Mezmo SRE
    Webinar Recap: Applying a Data Engineering Approach to Telemetry Data
    Dogfooding at Mezmo: How we used telemetry pipeline to reduce data volume
    Unlocking Business Insights with Telemetry Pipelines
    Why Your Telemetry (Observability) Pipelines Need to be Responsive
    How Data Profiling Can Reduce Burnout
    Data Optimization Technique: Route Data to Specialized Processing Chains
    Data Privacy Takeaways from Gartner Security & Risk Summit
    Mastering Telemetry Pipelines: Driving Compliance and Data Optimization
    A Recap of Gartner Security and Risk Summit: GenAI, Augmented Cybersecurity, Burnout
    Why Telemetry Pipelines Should Be A Part Of Your Compliance Strategy
    Pipeline Module: Event to Metric
    Telemetry Data Compliance Module
    OpenTelemetry: The Key To Unified Telemetry Data
    Data optimization technique: convert events to metrics
    What’s New With Mezmo: In-stream Alerting
    How Mezmo Used Telemetry Pipeline to Handle Metrics
    Webinar Recap: Mastering Telemetry Pipelines - A DevOps Lifecycle Approach to Data Management
    Open-source Telemetry Pipelines: An Overview
    SRECon Recap: Product Reliability, Burn Out, and more
    Webinar Recap: How to Manage Telemetry Data with Confidence
    Webinar Recap: Myths and Realities in Telemetry Data Handling
    Using Vector to Build a Telemetry Pipeline Solution
    Managing Telemetry Data Overflow in Kubernetes with Resource Quotas and Limits
    How To Optimize Telemetry Pipelines For Better Observability and Security
    Gartner IOCS Conference Recap: Monitoring and Observing Environments with Telemetry Pipelines
    AWS re:Invent 2023 highlights: Observability at Stripe, Capital One, and McDonald’s
    Webinar Recap: Best Practices for Observability Pipelines
    Introducing Responsive Pipelines from Mezmo
    My First KubeCon - Tales of the K8’s community, DE&I, sustainability, and OTel
    Modernize Telemetry Pipeline Management with Mezmo Pipeline as Code
    How To Profile and Optimize Telemetry Data: A Deep Dive
    Kubernetes Telemetry Data Optimization in Five Steps with Mezmo
    Introducing Mezmo Edge: A Secure Approach To Telemetry Data
    Understand Kubernetes Telemetry Data Immediately With Mezmo’s Welcome Pipeline
    Unearthing Gold: Deriving Metrics from Logs with Mezmo Telemetry Pipeline
    Webinar Recap: The Single Pane of Glass Myth
    Empower Observability Engineers: Enhance Engineering With Mezmo
    Webinar Recap: How to Get More Out of Your Log Data
    Unraveling the Log Data Explosion: New Market Research Shows Trends and Challenges
    Webinar Recap: Unlocking the Full Value of Telemetry Data
    Data-Driven Decision Making: Leveraging Metrics and Logs-to-Metrics Processors
    How To Configure The Mezmo Telemetry Pipeline
    Supercharge Elasticsearch Observability With Telemetry Pipelines
    Enhancing Grafana Observability With Telemetry Pipelines
    Optimizing Your Splunk Experience with Telemetry Pipelines
    Webinar Recap: Unlocking Business Performance with Telemetry Data
    Enhancing Datadog Observability with Telemetry Pipelines