Various metric formats are employed in monitoring systems to measure performance, consumption, and other software properties. These formats serve as standardized ways to represent and transmit metric data. Here are some notable metric formats used in monitoring systems:

Prometheus format

Prometheus, a widely used monitoring system, defines its format for metrics, including types like Counter, Gauge, Histogram, and Summary.

JSON format

JSON is a lightweight, easy-to-read data-interchange format.

Metric source classification

From a technical standpoint, there is no distinct categorization of metric sources. Any device, software, or application capable of generating and presenting metrics compatible with Prometheus is considered part of this group. Nonetheless, in most instances, the Prometheus agent emerges as the optimal solution. Here, we can name some common agents that are capable of producing Prometheus-compatible metrics:

• Prometheus

• Grafana Agent

• OpenTelemetry

• FluentBit

Metrics examples

Metrics in JSON format

{
  "input": {
    "cpu.0": {
      "records": 8,
      "bytes": 2536
    }
  },
  "output": {
    "stdout.0": {
      "proc_records": 5,
      "proc_bytes": 1585,
      "errors": 0,
      "retries": 0,
      "retries_failed": 0
    }
  }
}

Metrics in Prometheus format

fluentbit_input_records_total{name="cpu.0"} 57 1509150350542
fluentbit_input_bytes_total{name="cpu.0"} 18069 1509150350542
fluentbit_output_proc_records_total{name="stdout.0"} 54 1509150350542
fluentbit_output_proc_bytes_total{name="stdout.0"} 17118 1509150350542
fluentbit_output_errors_total{name="stdout.0"} 0 1509150350542
fluentbit_output_retries_total{name="stdout.0"} 0 1509150350542
fluentbit_output_retries_failed_total{name="stdout.0"} 0 1509150350542

Monitoring Service supports metrics from various Promethues compatible metric sources. Selected agents or exporters can push metrics to selected regional endpoint for ingestion. The collected metrics are processed, stored, and made available for querying and visualization.

Examples provide some suggested and functional Prometheus configurations for our available metric sources.

Prometheus

Prometheus is a monitoring and alerting toolkit that is designed for reliability and scalability. It is a pull-based system that scrapes metrics from instrumented jobs, either directly or via an intermediary push gateway for short-lived jobs. It stores all scraped samples locally and runs rules over this data to either aggregate and record new time series from existing data or generate alerts. We also recommend you try our sample configuration.

Grafana Agent

Grafana Agent is an OpenTelemetry Collector distribution with configuration inspired by Terraform. It is designed to be flexible, performant, and compatible with multiple ecosystems such as Prometheus and OpenTelemetry. We also recommend you try our sample configuration.

OpenTelemetry

OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics) to help you analyze your software’s performance and behavior. We also recommend you try our sample configuration.

FluentBit

FluentBit is a super fast, lightweight, and highly scalable logging and metrics processor and forwarder. It is the preferred choice for cloud and containerized environments. We also recommend you try our sample configuration. This repository provides a basic example of how to configure FluentBit to send metrics to the Ionos Monitoring Service.

The Monitoring Service provides a centralized and scalable solution for monitoring and analyzing your application and infrastructure metrics.

Product Overview

DCD How-Tos

API How-Tos

Quick Start

Frequently Asked Questions (FAQs)

A metric pipeline refers to an instance or configuration of the Monitoring Service you can create using the REST API. To create an instance of the Monitoring Service, you can request the designated regional endpoint based on your desired location:

• Berlin: https://monitoring.de-txl.ionos.com/pipelines

• Frankfurt: https://monitoring.de-fra.ionos.com/pipelines

• London: https://monitoring.gb-lhr.ionos.com/pipelines

• Paris: https://monitoring.fr-par.ionos.com/pipelines

• Logroño: https://monitoring.es-vit.ionos.com/pipelines

When creating a metric pipeline instance, you can define multiple metric streams within each pipeline. Each stream functions as a separate metric source, allowing you to organize and manage different sources of metrics within your monitoring system.

After the pipeline is set up, a unique endpoint is assigned to each pipeline, thus establishing a connection with an independent metric server. This endpoint serves as the designated destination for sending metrics generated by all the metric sources within the pipeline.

Contract limitations

The maximum number of pipelines you are allowed to create. The default value is 10. If you require a higher limitation boundaries, you can contact IONOS Cloud Support team to discuss your specific requirements and adjust the limits accordingly.

The Monitoring Service offers regional APIs that enable programmatic interaction with the platform. These APIs serve various purposes: task automation, system integration, and platform functionality extension. Additionally, the APIs allow you to filter metrics based on different criteria.

Sub-user access control

A sub-user is a user who has access to the Monitoring Service but is not an administrator or an owner. IONOS's crucial access control restriction does not allow sub-users to view or modify pipelines belonging to other sub-user accounts, except the primary administrator, who retains full cross-pipeline privileges. Ensure that the sub-user pipeline ownership and access permissions align with your organizational needs.

If a sub-user account creates a pipeline, access is restricted only to that sub-user and the primary administrator. Other sub-users cannot access or perform CRUD operations on the respective pipeline. For example, if sub-user A creates Pipeline 1, only sub-user A and the primary administrator account can view, edit, delete, or manage Pipeline 1. No other sub-user accounts will have access to it.

Regional REST API endpoint

A regional endpoint is necessary to interact with the Monitoring Service REST API endpoints. Currently, IONOS supports only the following regions for the Monitoring Service:

• Berlin: https://monitoring.de-txl.ionos.com/pipelines

• Frankfurt: https://monitoring.de-fra.ionos.com/pipelines

• London: https://monitoring.gb-lhr.ionos.com/pipelines

• Paris: https://monitoring.fr-par.ionos.com/pipelines

• Logroño: https://monitoring.es-vit.ionos.com/pipelines

Request parameter headers

To interact with the Monitoring Service REST API endpoints, the header must contain the following values:

Quick Links

Here are some of the most common API How-Tos for the Monitoring Service:

We recommend you refer to the following after creating an instance via the API:

You can set user privileges for accessing and managing Monitoring Service via the DCD.

Quick Link

The following link redirects you to the relevant page.

Monitoring Service is a cloud-based service that allows you to ingest, aggregate, and analyze data to enhance your understanding of your system's performance and behavior. The service collects data from various parts of your environment into a central system that is responsible for storage, aggregation, visualization, and initiating automated responses and alert when certain conditions are met.

Components of Monitoring Service

The architecture of the Monitoring Service includes the following four main components that can be used to aggregate metrics from various sources, analyze the gathered metrics, and create visualizations for monitoring and report generation.

• Data Collection: Data collection involves gathering metrics to track system performance and health. During this phase, metrics are collected by an agent running on each monitored resource. These metrics are then pushed to the Monitoring Service, ensuring that all relevant performance and behavior data from various parts of the environment are efficiently gathered.

• Data Aggregation & Processing: Once the data reaches the Monitoring Service, it undergoes aggregation and processing. This step prepares the data for storage by transforming and organizing it to optimize subsequent retrieval and analysis.

• Indexing & Storage: Indexing and storage in monitoring services ensure that collected data is organized and accessible for quick retrieval and analysis. Indexing involves creating searchable metadata for the data, enabling efficient queries. Storage involves saving the data in a scalable and durable manner, often using databases or specialized storage systems designed for high write and read performance.

• Visualization & Analysis: Visualization in monitoring services involves displaying collected and processed data in an intuitive and accessible format. Users can access their metrics for visualization, reporting, analysis, and alerting through a dedicated Grafana Instance. This provides comprehensive tools for interpreting the collected metrics, enabling informed decision-making and proactive system management.

With a properly implemented Monitoring Service and various metrics, the following is a brief list of advantages of Monitoring Service for clients:

• Centralized Metric Aggregation Users can push metrics from various Prometheus-compatible agents to a central endpoint, where the service aggregates and stores them for comprehensive analysis.

• Unified Querying Interface Metrics and logs (from the logging service) are accessible through a single Grafana instance, allowing users to perform detailed queries and gain insights across all their data sources.

• Scalable Architecture The service is designed to handle extensive volumes of metrics, with the ability to scale up or down according to user needs, ensuring consistent performance regardless of workload.

• High-Performance Data Processing Optimized for speed and efficiency, the service delivers rapid data ingestion, aggregation, and querying, enabling efficient monitoring and analysis.

Benefits

Besides all the topics listed in the features set, there are some more business-related benefits:

• Metrics Unification: Unify metrics across multiple data centers and applications, providing a holistic view of infrastructure and application performance.

• Reduced Cost By centralizing and scaling the monitoring infrastructure, users can lower costs associated with maintaining and operating separate monitoring solutions.

• Enhanced Data Consistency Aggregating all metrics in one place ensures consistent and accurate data, improving the reliability of insights and reporting.

• In-Depth Analysis Leverages Grafana's powerful visualization and exploration capabilities to uncover insights from metric data.

Deletes the specified Pipeline.

To delete a Pipeline, perform a DELETE request with the pipelineId of the pipeline.

Request

The following is a sample request. Remember to replace the {pipelineID} with a valid ID of the specific pipeline that must be deleted.

curl --location \
--request DELETE 'https://monitoring.de-txl.ionos.com/pipelines/{pipelineID}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer $TOKEN'

Response

202 Successful operation

{
    "description": "Deleting Pipeline was successful."
}

To find out the available types of metrics, we can start by looking at what type of information we can track.

Host-based metrics

These would be anything involved in evaluating the health or performance of an individual machine, disregarding for the moment its application stacks and services.

• CPU

• Memory

• Disk Space

• Processes

• Network traffic

• Storage 1/O

• System Metrics

Application metrics

These are metrics concerned with units of processing or work that depend on the host-level resources, like services or applications. The specific types of metrics to look at depend on what the service is providing, what dependencies it has, and what other components it interacts with.

• Error and success rates

• Service failures and restarts

• Performance and latency of responses

• Resource usage

Network and connectivity metrics

These are important gauges of outward-facing availability but are also essential in ensuring that services are accessible to other machines for any systems that span more than one machine.

• Connectivity

• Error rates and packet loss

• Latency

• Bandwidth utilization

Server pool metrics

While metrics about individual servers are useful, at scale a service is better represented as the ability of a collection of machines to perform work and respond adequately to requests. This type of metric is in many ways just a higher-level extrapolation of application and server metrics, but the resources in this case are homogeneous servers instead of machine-level components.

• Pooled resource usage

• Scaling adjustment indicators

• Degraded instances

External dependency metrics

Other metrics you may wish to add to your system are those related to external dependencies. Often, services provide status pages or an API to discover service outages, but tracking these within your systems—as well as your actual interactions with the service—can help you identify problems with your providers that may affect your operations.

• Service status and availability

• Success and error rates

• Run rate and operational costs

• Resource exhaustion

Monitoring Service ingests data from various parts of your environment into a central system that is responsible for storage, aggregation, visualization, and initiating automated responses and alert when certain conditions are met.

Scenario 1: Application Performance Monitoring

Precondition

An e-commerce company wants to ensure its web application performs optimally, especially during peak traffic periods like holiday sales.

Solution

The Monitoring Service continuously tracks application metrics such as response time, error rates, and throughput. Custom alerts are set up to notify the IT team if response times exceed acceptable thresholds or if error rates spike.

Scenario 2: Infrastructure Monitoring

Precondition

A financial institution needs to monitor its server infrastructure to ensure high availability and reliability of its online banking services.

Solution

The Monitoring Service collects metrics from servers, such as CPU usage, memory usage, disk I/O, and network traffic. Dashboards in Grafana provide real-time visualization, and alerts are configured for resource utilization thresholds.

Scenario 3: Security Monitoring

Precondition

A healthcare provider needs to ensure the security and compliance of its systems that handle sensitive patient data.

Solution

The Monitoring Service tracks security-related metrics such as failed login attempts, unauthorized access attempts, and unusual network activity. Alerts are configured for suspicious activities, and detailed logs are stored for compliance audits.

Scenario 4: DevOps and Continuous Integration

Precondition

A software development team wants to monitor the performance and stability of applications throughout the CI/CD pipeline.

Solution

The Monitoring Service is integrated with the CI/CD tools to collect metrics from development, staging, and production environments. Metrics such as build times, deployment success rates, and test coverage are tracked and visualized in Grafana.

Scenario 5: IoT Device Monitoring

Precondition

A smart home company needs to monitor thousands of IoT devices deployed in customers homes to ensure they are functioning correctly.

Solution

The Monitoring Service collects metrics from IoT devices, such as battery levels, connectivity status, and sensor readings. Alerts are configured for critical metrics, and dashboards provide an overview of device health and performance.

Scenario 6: Business Metrics Monitoring

Precondition

A SaaS company wants to track key business metrics such as user sign-ups, subscription renewals, and revenue growth.

Solution

The Monitoring Service collects business-related metrics and integrates them into Grafana dashboards. Custom alerts are set up to notify the team of significant changes in business metrics.

Scenario 7: Network Monitoring

Precondition

An Internet Service Provider (ISP) needs to monitor its network infrastructure to ensure high availability and performance for its customers.

Solution

The Monitoring Service collects network metrics such as latency, packet loss, and bandwidth usage. Dashboards in Grafana provide real-time visualization of network performance, and alerts are configured for network anomalies.

Users need appropriate privileges to access, create, and modify Monitoring Service. Without necessary privileges, users have a read-only access and cannot provision changes. You can grant appropriate privileges via the User Manager.

To allow users to access, create, and modify the Monitoting Service, follow these steps:

1. Log in to the DCD with your username and password.

2. In the DCD menu, select Management > Users & Groups under Users.

3. Select the Groups tab in the User Manager window.

4. Select the appropriate group to assign relevant privileges.

5. In the Privileges tab, select Access and manage Monitoring to allow the associated group members to access and manage Monitoring Service.

Create and manage sub-users

For improved user management and delegation, you can establish sub-users and grant them the necessary permissions to use the Monitoring Service. Sub-users can be given varying levels of access for their segment of the monitoring pipeline by the primary account owners. Only the pipelines that the primary account owner has assigned to sub-users are visible to them and can be managed, but they cannot access the primary account or pipelines created by other sub-users.

To create sub-users, follow these steps:

1. Log in to the DCD with your username and password.

2. In the DCD menu, select Management > Users & Groups under Users.

3. Select the Groups tab in the User Manager window.

4. Select the appropriate group to assign relevant privileges.

5. In the Members tab, click + Add User and select a user(s) from the list.

To delete an associated sub-user, click Remove User.

To create or update a Pipeline, you need to provide the complete Pipeline configuration. If you wish to create a new Pipeline or modify an existing one with a specified ID, you should include all necessary details in your request. Optional fields will be automatically populated with default values or left empty if not provided. To ensure that the Pipeline is created or updated correctly, perform a PUT request with the full Pipeline data.

Pipeline authentication for secure metric ingestion

To ensure secure and authorized metric data submission, each Monitoring Pipeline is assigned a unique key upon creation. This key acts as a credential for metric exporters or agents pushing data to the pipeline's HTTP endpoint.

Key points

• The key is included in the metadata section of the pipeline response (see "key": "momSrlgAAEmaYEvBsMr^HsYn" in the example).

• Metric exporters or agents must be configured to include this key in their requests to the pipeline's HTTP endpoint for successful data ingestion.

• This mechanism safeguards the pipeline from unauthorized data submissions and maintains data integrity within the Monitoring Service.

Best practices

• Store the pipeline key securely for authorized metric sources only.

• Avoid sharing or exposing the key publicly.

• Consider periodically for enhanced security.

To create a Monitoring Pipeline, perform a POST request.

Request

Response

The following is a sample response. The values returned by each response differ based on the request.

To obtain a new key, perform a PUT request with the complete key configuration. Ensure that you specify all the mandatory details. The optional fields will be automatically populated with default values or left empty if not specified.

Request

To get a new key for a pipeline, you can use the following request. Remember to replace the {pipelineID} with a valid ID of a pipeline to access its key.

Response

Generates a new key for a pipeline invalidating the old one. The key is used for authentication when sending metrics.

Returns the Monitoring Pipeline by ID.

To retrieve a Monitoring Pipeline, perform a GET request.

Request

Response

The following is a sample response. The values returned by each response differ based on the request.

200 Successful operation

This endpoint enables retrieving all pipelines using pagination and optional filters.

To retrieve all the Monitoring Pipelines, perform a GET request.

Request

The following is a sample request.

Response

The following is a sample response. The values returned by each response differ based on the request.

200 Successful operation

Ensures that the pipeline with the provided ID is created or modified. The full pipeline needs to be provided to ensure (either update or create) the pipeline. Non present data will only be filled with defaults or left empty, but not take previous values into consideration.

To ensure that the pipeline with the provided ID is created or modified, perform PUT request.

Request

The following is a sample request. Remember to replace the {pipelineID} with a valid ID of the specific pipeline you want to create or update.

Response

The following is a sample response. The values returned by each response differ based on the request.

200 Successful operation

An observability platform is necessary for visualization and reporting purposes. IONOS uses to enable you to meet your visualization needs.

Grafana access for sub-users

Sub-users in your contract number can access Grafana with their IONOS credentials, subject to the following conditions:

• At least one pipeline must be connected to the contract number.

• Sub-users must be active and have the to access Monitoring Service.

If you are unable to log into Grafana, ensure that you have checked the following:

• The sub-user is active and has the necessary privileges to access the Monitoring Service.

• The contract number contains at least one monitoring pipeline.

• The sub-user uses the correct email address associated with the contract number.

If the issue persists, contact .

You can obtain your Grafana instance address by sending a GET request to the server. For more information, see . The response contains the grafanaEndpoint. This information remains the same for all your monitoring pipelines.

You can send metrics from anywhere as long as you can reach the Prometheus endpoint.

You can find some examples to configure available metric sources with Prometheus.

FluentBit

This repository provides a basic example of how to configure FluentBit to send metrics to the IONOS Monitoring Service.

Provision a pipeline

Provision a monitoring pipeline using REST API https://monitoring.de-txl.ionos.com/pipelines.

Example API Request Body

{
  "properties": {
    "name": "example"
  }
}

Usage

1. Grab the key from the above response or provision a new key using REST API https://monitoring.de-txl.ionos.com/pipelines/<PIPELINE_ID>/key.

2. Install FluentBit package, appropriate for your distribution.

3. Update the HTTP endpoint and the APIKEY in the fluentbit.conf file.

4. Configure FluentBit to your desired state.

5. Run FluentBit and Profit.

Grafana Agent

This example shows how to configure Grafana Agent to send metrics to the monitoring pipeline.

Provision a pipeline

Provision a monitoring pipeline using REST API https://monitoring.de-txl.ionos.com/pipelines.

Example API Request Body

{
  "properties": {
    "name": "example"
  }
}

Usage `

1. Grab the key from the above response or provision a new key using REST API https://monitoring.de-txl.ionos.com/pipelines/<PIPELINE_ID>/key.

2. Install Grafana Agent package, appropriate for your distribution. (https://grafana.com/docs/agent/latest/about/)

3. Update the HTTP endpoint and the APIKEY in the config file.

  prometheus.remote_write "LABEL" {
    endpoint {
      url = "your pipeline's httpEndpoint"

      headers = {
        "APIKEY" = "<API_KEY>",
      }
  }
}

Prometheus

Prometheus is a monitoring and alerting toolkit that is designed for reliability and scalability. It is a pull-based system that scrapes metrics from instrumented jobs, either directly or via an intermediary push gateway for short-lived jobs. It stores all scraped samples locally and runs rules over this data to either aggregate and record new time series from existing data or generate alerts.

Provision a pipeline

Provision a monitoring pipeline using REST API https://monitoring.de-txl.ionos.com/pipelines.

Example API Request Body

{
  "properties": {
    "name": "example"
  }
}

Usage

1. Grab the key from the above response or provision a new key using REST API https://monitoring.de-txl.ionos.com/pipelines/<PIPELINE_ID>/key.

2. Install Prometheus package, appropriate for your distribution.

3. Update the HTTP endpoint and the APIKEY in the prometheus config file.

url: "your pipeline's httpEndpoint"
headers:
  APIKEY: "<APIKEY>"

OpenTelemetry

OpenTelemetry is a set of APIs, libraries, agents, and instrumentation to provide observability for cloud-native software. It is a CNCF project.

Provision a pipeline

Provision a monitoring pipeline using REST API https://monitoring.de-txl.ionos.com/pipelines.

Example API Request Body

{
  "properties": {
    "name": "example"
  }
}

Usage

1. Grab the key from the above response or provision a new key using REST API https://monitoring.de-txl.ionos.com/pipelines/<PIPELINE_ID>/key.

2. Update the HTTP endpoint and the APIKEY in the config file.

exporters:
  prometheusremotewrite:
    endpoint: "your pipeline's httpEndpoint"
    external_labels:
      APIKEY: <API_KEY>
      label_name2: label_value2

What is Monitoring Service?

The Monitoring Service offers a centralized and scalable solution for monitoring and analyzing your application and infrastructure metrics. It enables you to track performance, detect issues proactively, and ensure optimal operation across your systems.

What types of metrics can be monitored?

The Monitoring Service supports a wide range of metrics, including system performance, application performance, network traffic, and custom metrics specific to your applications. Metrics must be Prometheus-compatible.

How frequently are metrics pushed to the server?

Metrics are pushed to our servers at configurable intervals to match your monitoring needs. The default push interval is one minute. You can adjust this interval based on your requirements.

Can I set up custom alerts for specific metrics?

Yes, you can easily configure custom alerts directly within Grafana for specific metrics. The Monitoring Service utilized Grafana for visualization, allowing you to define alert conditions, thresholds, and notification preferences.

How secure is the data collected by the Monitoring Service?

The Monitoring Service employs multiple layers of security to ensure data protection:

• Transport Layer Security (TLS): Data is encrypted during transmission.

• Data Partitioning: Each user's data is stored in separate partitions to ensure isolation.

• Encryption: Both server-side and client-side encryption are used to secure data at rest.

Can I customize the dashboards in the Monitoring Service?

Yes, Monitoring Service offers powerful dashboard customization capabilities through Grafana. Create, modify, and share interactive dashboards to visualize your data in the way that best suits your needs. Grafana's rich feature set allows you to build highly informative and engaging dashboards.

How do I manage user access to the Monitoring Service?

User access is managed through a robust role-based access control Role-Based Access Control (RBAC) system. Administrators can create user accounts, assign roles, and define permissions to control access to different features and data within the Monitoring Service.

What is the difference between Monitoring as a Service and Monitoring Service?

Can I restrict the traffic sent to Monitoring Service endpoints?

Yes, we recommend configuring firewall rules using the authorized IP addresses associated with each endpoint to restrict the traffic to Monitoring Service endpoints. The following is a list of locations and their specific IP addresses:

What is Cloud Native Computing Foundation?

The Cloud Native Computing Foundation (CNCF) is part of the Linux Foundation, focused on advancing cloud-native technologies. It hosts projects like Kubernetes and Prometheus, provides certification, and promotes standards for cloud-native computing.

For more details, visit the CNCF website.

After creating a monitoring pipeline via the , complete the monitoring pipeline configuration process using the following: