Using ContainIQ

By using eBPF, ContainIQ is able to monitor from the kernel and OS level, and not at the application level, we can deliver information immediately by parsing the network packet from the socket directly, without users having to instrument each microservice at the application level.

Request Tracing

ContainIQ’s tracing feature set and dashboard give users real-time tracing data for all URL paths, without having to instrument each microservice at the application level. Graph P99, P95, average latency, and error rate over time for each URL path or use the table to analyze trace details such as HTTP method, HTTP status code for each request. To correlate logs to a specific path, click into trace from the table to reveal the corresponding logs for a given point in time. 

Trace Logs

To correlate logs for a specific trace, users will need to select a trace from the table below the graph or search for a specific trace using the search feature located at the top of the dashboard. Once the trace is found, click and a drop-down will appear with all associated logs for that trace at the given point in time.

Search and Filtering

Users can search traces by timestamp, or URL path. Paths can be searched for individually or grouped with regular expression. Users are also able to filter traces by cluster, namespace, or time range.

Advanced Filtering

Advanced filtering allows users to filter by a number of different variables: path, pod name, protocol, method, status code, and latency timestamps. Users can build queries using single variables or by combining multiple variables.

Document image


ContainIQ’s latency dashboard allows users to graph and set alerts P95 latency, P99 latency, avg. latency and requests per second across all of their different Kubernetes services. No application package installations necessary.

Latency by Microservice

To view latency by microservice, users can navigate to our Latency dashboard where they are shown a list of all active microservices and their corresponding P95 latency, P99 latency, avg. latency and requests per second. 

Our graph view can help users quickly identify spikes in latency across each microservice. To graph these metrics over time, users can first select the desired microservice from the drop-down inside the graph. Then users can specify the time range to look into by using the time range selector, located in the top right corner of the navigation. Here users can specify the exact time range they’d like to look into, as well as, view data by minute, hour, or day.

Latency by URL Paths or API Endpoint

By clicking on a microservice from our Latency dashboard, users will be presented with a modal where they can see requests per second and various latency metrics for each URL path or API endpoint within the given microservice. Users are able to search through endpoints by utilizing the search bar, or by manually paginating through, in addition to search, users can filter endpoint metrics by the past hour, day.

Document image


ContainIQ’s metrics dashboards give users a comprehensive view of cluster health. Helping users understand both the real-time and historical state of their clusters. These dashboards offer three charts: our hive chart (real-time metrics, conditions, events), historical pod and node metrics (view CPU and Memory usage over time, view CPU and Memory utilization), and Avg. CPU and Memory (view spikes in CPU or Memory over the last hour). 

Hive Chart

By using our hive chart, users can view real-time pod and node CPU and memory, color-coded based on relative usage. From here, users are able to view pod/node conditions, view events related to a specific pod or node, and dive into what pods are assigned to what node.

Historical pod and node metrics

The two graphs under the hive chart show available vs. used CPU and Memory limits over time. These metrics can be used to rightsize clusters or monitor resource limits that have already been set. Users can view this data by hour, day, or week.

Average CPU and Memory

The bottom two graphs can be used to identify any spikes in CPU and Memory usage across all pods or nodes over the last hour.

Document image


ContainIQ’s events dashboard enables users to view events over time, search for specific events, filter based on event type, filter based on namespace, and set alerts for specific events like crash loops, pod evictions, and failed Kubernetes jobs.

Correlate Pod Events to Logs

For debugging purposes, users are able to easily correlate pod events to logs directly from the events dashboard. Simply click on the description of the pod event and ContainIQ will take users to the logs for that specific point in time.

Filter by Event Type

By default, the events dashboard shows all events (normal and warning) users can choose to view both or look into all warning events or normal events. To do this simply click the event type filter in the secondary navigation bar and choose either event type: all, normal, or warning.

Filter by Namespace

Users can view events by namespace. Instead of sifting through events, users can drill down into a specific namespace and view and search events for a particular namespace.

Search Events by Name or Message

Along with our filters users can search events by name or description. Users can search events across their entire cluster or filter by namespace, event type, and time range. 

Document image


ContainIQ automatically collects anything logged inside a user’s cluster encompassing both internal applications and Kubernetes system components. Users can search through logs by cluster, pod, container, message, timestamp, regex, or JSON path.

ContainIQ offers both basic and advanced log search functionality. Basic log search allows users to search across their clusters by pod, message, and time range. To do this users can use the search located in the navigation bar or click into a pod to get all corresponding logs for that specific pod.

Users can also take their search queries one step further with our advanced search functionality. Here users are able to build log queries by pod name, message, container name, stream, or JSON message.

Searching by JSON message allows users to parse by key-value pairs, making it easier to aggregate and filter JSON formatted log messages.

Document image

Monitors and Alerts

Users can set up monitors to send alerts across all data points (ex. P95 latency, a Kubernetes job failing, a pod eviction, etc).

Setting up Slack Alerts

To deliver alerts, users must integrate ContainIQ with Slack and set up a channel for alerts to feed into. To do this navigate to the user settings page, on the left navigation click into the “Integration” tab and then click “Activate” under actions. From here, the user will be prompted to choose the appropriate Slack channel they would like to integrate with, as well as, selecting or creating the channel the alerts should feed into. Once a channel is selected or a new channel is created, click allow to enable the ContainIQ and Slack integration.

Creating a New Monitor

Monitors are easy to set up. Click the “New Monitor” button located in the uppermost navigation bar. From here, the user will be prompted to create a new monitor. Here users can input the name of the new monitor, choose the alert type (event or metric) and then set appropriate variables. 

Creating an Event Monitor

Event monitors are the most straightforward to set up. To create an event monitor users will need to do the following: 

  • Create a “New Monitor” 
  • Name the monitor
  • Choose alert type - Event
  • Press Continue
  • Input the Event reason to be alerted on i.e. Backoff
  • To target a specific object (container, pod name, node, etc) enter the name of the object.
    • To target all events select “Matches All” from the Event Object dropdown. 
  • Press Create Event Monitor
Document image

Creating a Metric Monitor

To create a metric monitor users will need to do the following: 

  • Create a “New Monitor” 
  • Name the monitor
  • Choose alert type - Metric
  • Choose whether you would like to alert on a specific threshold or % change
  • Press Continue
  • If alerting on threshold the user will then be prompted to enter their threshold conditions,
    • Select what metric to be alerted on (pod CPU, node CPU, pod memory, node memory, avg. latency, P95 latency, or P99 latency)
    • And finally, input the name of the specific pod or node to target.
  • If a specific object  (container, pod, node, etc)  is being targeted, enter the name of the object.
    • To target all events select “Matches All” from the Event Object dropdown. 
  • Press Create Event Monitor

Document image

Any new monitor that is created will be turned on by default. 

Turning off Monitors

Monitors can be turned off by way of the Monitors dashboard. This dashboard provides a list of all monitors, from here users can see monitor name, type, toggle notifications on or off, and edit existing monitors. 

To turn off a monitor, simply click the toggle located on the right side of the table. ContainIQ also allows users to perform bulk actions on this dashboard, users can select multiple monitors and turn them on or off, or delete them.

Updated 23 Mar 2022
Did this page help?