Docker and Nebius Cloud Monitoring Integration

Input and output integration overview

The Docker input plugin allows you to collect metrics from your Docker containers using the Docker Engine API, facilitating enhanced visibility and monitoring of containerized applications.

This plugin allows users to effortlessly send aggregated metrics to Nebius Cloud Monitoring, leveraging the cloud’s monitoring solutions.

Integration details

Docker

The Docker input plugin for Telegraf gathers valuable metrics from the Docker Engine API, providing insights into running containers. This plugin utilizes the Official Docker Client to interface with the Engine API, allowing users to monitor various container states, resource allocations, and performance metrics. With options for filtering containers by names and states, along with customizable tags and labels, this plugin supports flexibility in monitoring containerized applications in diverse environments, whether on local systems or within orchestration platforms like Kubernetes. Additionally, it addresses security considerations by requiring permissions for accessing Docker’s daemon and emphasizes proper configuration when deploying within containerized environments.

Nebius Cloud Monitoring

The Nebius Cloud Monitoring plugin serves as an intermediary to send custom metrics to the Nebius Cloud Monitoring service. It is designed specifically to facilitate the monitoring of applications and services running within the Nebius ecosystem. This plugin is especially useful for users of the Nebius Cloud Platform who need to leverage cloud-based monitoring capabilities without significant configuration overhead. The plugin’s integration relies on Google Cloud metadata, allowing it to automatically fetch the necessary authentication credentials from the Compute instance it operates within. Key technical considerations include the management of reserved labels to ensure metrics are recorded correctly without conflicts.

Configuration

Docker

[[inputs.docker]]
  ## Docker Endpoint
  ##   To use TCP, set endpoint = "tcp://[ip]:[port]"
  ##   To use environment variables (ie, docker-machine), set endpoint = "ENV"
  endpoint = "unix:///var/run/docker.sock"

  ## Set to true to collect Swarm metrics(desired_replicas, running_replicas)
  ## Note: configure this in one of the manager nodes in a Swarm cluster.
  ## configuring in multiple Swarm managers results in duplication of metrics.
  gather_services = false

  ## Only collect metrics for these containers. Values will be appended to
  ## container_name_include.
  ## Deprecated (1.4.0), use container_name_include
  container_names = []

  ## Set the source tag for the metrics to the container ID hostname, eg first 12 chars
  source_tag = false

  ## Containers to include and exclude. Collect all if empty. Globs accepted.
  container_name_include = []
  container_name_exclude = []

  ## Container states to include and exclude. Globs accepted.
  ## When empty only containers in the "running" state will be captured.
  # container_state_include = []
  # container_state_exclude = []

  ## Objects to include for disk usage query
  ## Allowed values are "container", "image", "volume" 
  ## When empty disk usage is excluded
  storage_objects = []

  ## Timeout for docker list, info, and stats commands
  timeout = "5s"

  ## Whether to report for each container per-device blkio (8:0, 8:1...),
  ## network (eth0, eth1, ...) and cpu (cpu0, cpu1, ...) stats or not.
  ## Usage of this setting is discouraged since it will be deprecated in favor of 'perdevice_include'.
  ## Default value is 'true' for backwards compatibility, please set it to 'false' so that 'perdevice_include' setting
  ## is honored.
  perdevice = true

  ## Specifies for which classes a per-device metric should be issued
  ## Possible values are 'cpu' (cpu0, cpu1, ...), 'blkio' (8:0, 8:1, ...) and 'network' (eth0, eth1, ...)
  ## Please note that this setting has no effect if 'perdevice' is set to 'true'
  # perdevice_include = ["cpu"]

  ## Whether to report for each container total blkio and network stats or not.
  ## Usage of this setting is discouraged since it will be deprecated in favor of 'total_include'.
  ## Default value is 'false' for backwards compatibility, please set it to 'true' so that 'total_include' setting
  ## is honored.
  total = false

  ## Specifies for which classes a total metric should be issued. Total is an aggregated of the 'perdevice' values.
  ## Possible values are 'cpu', 'blkio' and 'network'
  ## Total 'cpu' is reported directly by Docker daemon, and 'network' and 'blkio' totals are aggregated by this plugin.
  ## Please note that this setting has no effect if 'total' is set to 'false'
  # total_include = ["cpu", "blkio", "network"]

  ## docker labels to include and exclude as tags.  Globs accepted.
  ## Note that an empty array for both will include all labels as tags
  docker_label_include = []
  docker_label_exclude = []

  ## Which environment variables should we use as a tag
  tag_env = ["JAVA_HOME", "HEAP_SIZE"]

  ## Optional TLS Config
  # tls_ca = "/etc/telegraf/ca.pem"
  # tls_cert = "/etc/telegraf/cert.pem"
  # tls_key = "/etc/telegraf/key.pem"
  ## Use TLS but skip chain & host verification
  # insecure_skip_verify = false

Nebius Cloud Monitoring

[[outputs.nebius_cloud_monitoring]]
  ## Timeout for HTTP writes.
  # timeout = "20s"

  ## Nebius.Cloud monitoring API endpoint. Normally should not be changed
  # endpoint = "https://monitoring.api.il.nebius.cloud/monitoring/v2/data/write"

Input and output integration examples

Docker

1. Monitoring the Performance of Containerized Applications: Use the Docker input plugin in order to track the CPU, memory, disk I/O, and network activity of applications running in Docker containers. By collecting these metrics, DevOps teams can proactively manage resource allocation, troubleshoot performance bottlenecks, and ensure optimal application performance across different environments.

2. Integrating with Kubernetes: Leverage this plugin to gather metrics from Docker containers orchestrated by Kubernetes. By filtering out unnecessary Kubernetes labels and focusing on key metrics, teams can streamline their monitoring solutions and create dashboards that provide insights into the overall health of microservices running within the Kubernetes cluster.

3. Capacity Planning and Resource Optimization: Use the metrics collected by the Docker input plugin to perform capacity planning for Docker deployments. Analyzing usage patterns helps identify underutilized resources and over-provisioned containers, guiding decisions on scaling up or down based on actual usage trends.

4. Automated Alerting for Container Anomalies: Set up alerting rules based on the metrics collected through the Docker plugin to notify teams of unusual spikes in resource usage or service disruptions. This proactive monitoring approach helps maintain service reliability and optimize the performance of containerized applications.

Nebius Cloud Monitoring

1. Dynamic Application Monitoring: Integrate this plugin with your application to continuously send metrics related to resource usage, such as CPU and memory utilization, to Nebius Cloud Monitoring. By doing so, you can gain insights into the performance of your application, allowing for adjustments in real-time based on the metrics received.

2. Incident Response Automation: Use the Nebius Cloud Monitoring plugin to automatically send alerts and metrics when certain thresholds are reached. For instance, if a particular service’s uptime drops below a certain percentage, the plugin can be configured to report this directly to the monitoring service, enabling quicker incident response and resolution.

3. Comparative Service Analysis: Set up the plugin to send metrics from multiple cloud instances running different versions of the same application to Nebius Cloud Monitoring. This approach allows for a comparative analysis of resource usage and performance, helping teams determine which version performs best under similar workloads.

4. Aggregated Metrics Dashboard: Use this plugin to create a centralized dashboard displaying metrics from various services across your cloud instances. By aggregating different application metrics into one interface, stakeholders can assess the overall health and performance of their cloud environment easily.

Feedback

Thank you for being part of our community! If you have any general feedback or found any bugs on these pages, we welcome and encourage your input. Please submit your feedback in the InfluxDB community Slack.