DOCSEARCHbyAlgolia
Submit Docs

Circonus Documentation

website·Indexed 35 days ago

https://docs.circonus.com/

Documentation for Circonus, a distributed system for telemetry data collection and analysis. Includes guides for on-premises installation, system architecture, and roles such as the Circonus Unified Agent (CUA), IRONdb data storage, and the CAQL Broker. Covers system monitoring, data flow, LDAP authentication, and the management of metrics, checks, and dashboards.

Tokens
100.5K
Snippets
384
Records
951
Agent score
61%

What's inside Circonus

  1. Overview of Node Agent Daemon (NAD)

    Node Agent Daemon (NAD) is a lightweight host agent written in Node.js used to monitor system metrics. It is designed for extensibility and cross-platform compatibility, supporting Windows, RHEL, Ubuntu, and Illumos derivatives. NAD uses a 'pull' dataflow and defaults to port 2609. It executes plugins and scripts located in its configuration directory to collect metrics.

  2. Overview of Circonus Integrations

    Integrations in Circonus enable the collection of metrics using a poll-based method. Metrics can be collected either via the Circonus Unified Agent (CUA) deployed on a host or directly from a Circonus account using a specified broker for remote execution. Available integrations for cloud, infrastructure, and applications can be found in the Integrations Library within the primary navigation of the Circonus account.

  3. Overview of the Circonus Monitoring Platform

    Circonus is a full-stack enterprise monitoring platform designed to provide real-time observability into the behavior, health, trends, and performance of infrastructure and applications. The primary workflow for getting started involves creating an account, installing the Circonus Unified Agent (CUA) on a host, configuring integrations, and submitting system metrics to the platform.

  4. Overview of Node Windows Agent (NAD)

    The Node Windows Agent (NAD) is a pull-based agent used to collect Windows-specific metrics via Windows Management Instrumentation (WMI). It is specifically designed for users who cannot or do not want to install .NET 4.0 or the standard Windows Agent Check. The agent listens on port 2609 by default. Note that the metrics returned depend on the category selected during the creation process; if a category has no available metrics, only services [0] will be returned.

  5. Overview of Circonus Analytics Query Language (CAQL)

    CAQL is a Domain Specific Language (DSL) used to fetch, aggregate, and transform metric data across thousands of metrics. It is primarily used for visualizing data on graphs and driving alerting rules.

  7. Overview of Circonus Agent and NAD Compatibility

    The circonus-agent is a Go-based drop-in replacement for NAD.

    Critical Compatibility Notes:

    • Native Plugins: JavaScript (.js) native plugins are NOT supported unless modified to run node independently and follow plugin output guidelines.
    • Metric Continuity: Version 1+ of the agent supports stream tags only, which will change metric names if dropped into an existing NAD install. To maintain metric name continuity, use v0 releases.

  8. Overview of the Circonus Hub role

    The Hub role is an all-purpose role containing various services and cronjobs for Circonus. All Hub services log to the /var/log/circonus directory, with log files named after the specific process. Most service issues can be resolved by restarting the affected service.

  9. Overview of the Circonus Message Queue (MQ) role

    The Circonus Message Queue (MQ) role manages message passing between systems like stratcon, fault detection, and notification. It is split into two planes:

    • FQ (Data Plane): Handles the actual flow of metric data using a high-performance publish-subscribe model.
    • RabbitMQ (Control Plane): Handles signaling messages between components (e.g., Fault Detection notifying the Notification service of a new alert).

  10. Overview of IRONdb® (circonus-snowth) in Circonus deployments

    In a full Circonus deployment, the Data Storage component is branded as IRONdb® but runs as the service circonus-snowth (on EL7). It consists of a parent process (watchdog) and a child process.

    Network Ports:

    • External: 8112
    • Local: 32322

    Configuration:

    • The configuration file is snowth.conf.
    • This file is managed by Hooper; manual changes will be overwritten.
    • All configurable options should be managed via site.json under the data storage attributes.

  11. Overview of the Circonus Notification System

    The notification role manages services that create alerts based on output from the fault detection system and notify contact groups via configured methods. The primary service is circonus-bert (a Java process), which receives messages from the fault detection service via the MQ.

    circonus-bert exposes an internal metrics API on port 8084 at http://hostname:8084/resmon with the following sections:

    • main: Boot time and uptime
    • cases: Active and created alert counts
    • timers: Started timer counts
    • contact: Usage counts per contact method
    • noit_maintenance: Broker maintenance status (epoch time if non-zero)
    • mq: Messages sent/received on the MQ

    Detailed logs are located at /var/log/circonus/bert.log (rotated every 50MB, keeping the 25 most recent files).