LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Logging infrastructure
  • Logging levels
  • Viewing logs
  • Best practices

Was this helpful?

  1. Development
  2. Devops

Logging

PreviousEnvironment SetupNextMetrics

Last updated 2 years ago

Was this helpful?

Logging is one of the foundational pieces of telemetry we need to understand issues at runtime. It is therefore deemed one of the core responsibilities of developers to provide meaningful logs.

Logging infrastructure

Developers should use the logging library that is part of the monorepo and is configured for local as well as production environments. Don't use other methods of logging since that could lead to log statements not getting delivered correctly to the central log store.

Logging levels

The logging levels to be used are error, warn,info and debug. Everything from level info and up (that's info, error and warn) are delivered to the central log store. You can use all the levels of course but the logs with logging level lower than info will be discarded when deployed to one of the environments. We can change the logging level for a specific service to a lower level but that is a manual operation, to be used only as a last resort.

Example -

Viewing logs

You can search for and view the logs from all environments at .

Best practices

Use error when you are reporting errors or exceptions.

Use warn when things are in 'suspicious' or potentially problematic state.

Use info when reaching important states - server started, user created, registration complete, etc. or anything worth knowing about

Use debug for additional info.

Avoid logging at level info inside unbounded loops.

Don't log the same exception/error multiple times.

Do not log full personal identifiable or other sensitive information. User database IDs are preferred to users' names for example.

logging
https://app.datadoghq.eu/logs