Logging, Monitoring, and Debugging

On This Page


There are a variety of ways in which you can monitor, log, and debug the execution of platform application services, tools, and APIs.

For further troubleshooting assistance, visit Iguazio Support.

Logging Application Services

The platform has a default tenant-wide log-forwarder application service (log-forwarder) for forwarding application-service logs. The logs are forwarded to an instance of the Elasticsearch open-source search and analytics engine by using the open-source Filebeat log-shipper utility. The log-forwarder service is disabled by default. To enable it, on the Services dashboard page, select to edit the log-forwarder service; in the Custom Parameters tab, set the Elasticsearch URL parameter to an instance of Elasticsearch that will be used to store and index the logs; then, save and apply your changes to deploy the service.

Typically, the log-forwarder service should be configured to work with your own remote off-cluster instance of Elasticsearch.

  • The default transfer protocol, which is used when the URL doesn’t begin with “http://” or “https://”, is HTTPS.
  • The log-forwarder service doesn’t support off-cluster Elasticsearch user authentication, regardless of whether you use an HTTP or HTTPS URL.
  • The default port, which is used when the URL doesn’t end with “:<port number>”, is port 80 for HTTP and port 443 for HTTPS.

In cloud platform environments you can also configure the log-forwarder service to work with a tenant-wide Elasticsearch service that uses a pre-deployed on-cluster vanilla installation of Elasticsearch. To do so, you first need to create such an Elasticsearch service: from the Services dashboard page, select to create a new service of type “Elasticsearch”, optionally edit the default configuration, and apply your changes to deploy the service. You can then configure the log-forwarder service to forward the application-service logs to this service by selecting your Elasticsearch service from the drop-down list of the Elasticsearch parameter.

After enabling the log-forwarder service, you can view the forwarded logs in the Logs page of the platform dashboard (including filtering options), provided you have the Service Admin management policy. The Logs column on the Services dashboard page has links to filtered log views for each service.

Note that the Logs page displays all logs from the configured log-forwarder Elasticsearch instance, regardless of their origin. It’s therefore recommended that you use a dedicated Elasticsearch instance for each platform cluster that enables log forwarding.

Note that you cannot delete an Elasticsearch service while it’s being used by the log-forwarder service.

The Monitoring Application Service and Grafana Dashboards

The platform has a default tenant-wide monitoring application service (monitoring) for monitoring application services and gathering performance statistics and additional data. This service is enabled by default.

All Grafana user services in the platform that are created or restarted after the monitoring service is enabled have a default dashboards directory that contains the following predefined dashboards. The dashboards visualize data gathered by the monitoring service for application services of the parent tenant:

  • Application Services Monitoring — displays information for all the managed application services.
  • Nuclio Functions Monitoring - Overview — displays information for all the deployed serverless Nuclio functions.
  • Nuclio Functions Monitoring - Per Function — displays information for a specific Nuclio function, as set in the dashboard filter.

When there’s an enabled shared Grafana user service in the platform, the name of the monitoring service on the Services platform dashboard page (monitoring) links to the Application Services Monitoring dashboard of the shared Grafana service.

[Tech Preview] The platform also has a shared single-instance tenant-wide application-cluster Grafana service with monitoring dashboards for the entire Kubernetes application cluster (rather than a specific Kubernetes namespace like the dashboards for the Grafana user service). The dashboard are located under a default directory.
This service is accessible from the platform dashboard to users with the IT Admin management policy via a Status dashboard link on the Clusters | Application tab. The link opens the Kubernetes Cluster Status dashboard, but you can find additional dashboards in the parent default dashboards directory.


Several platform features rely on the monitoring service of the parent tenant, including the following:

  • The application-services and Nuclio-functions monitoring data that’s displayed in the platform dashboard and in the platform’s Grafana monitoring dashboards. Note that the predefined monitoring Grafana dashboards display information only when the monitoring service is enabled; the service is enabled by default.
  • Auto scaling of Nuclio functions.

Kubernetes Tools

You can use the Kubernetes kubectl CLI from a platform web-shell or Jupyter Notebook application service to monitor, log, and debug your Kubernetes application cluster:

  • Use the get pods command to display information about the cluster’s pods:
    kubectl get pods
  • Use the logs command to view the logs for a specific pod; replace POD with the name of one of the pods returned by the get command:
    kubectl logs POD
  • Use the top pod command to view pod resource metrics and monitor resource consumption; replace [POD] with the name of one of the pods returned by the get command or remove it to display logs for all pods:
    kubectl top pod [POD]

To run kubectl commands from a web-shell service, the service must be configured with an appropriate service account; for more information about the web-shell service accounts, see the web-shell introduction.

  • The get pods and logs commands require the “Log Reader” service account or higher.
  • The top pod command requires the “Service Admin” service account.

For more information about the kubectl CLI, see the Kubernetes documentation.

Event Logs

The Events page of the dashboard displays different platform event logs:

  • The Event Log tab displays system event logs.
  • The Alerts tab displays system alerts.
  • The Audit tab displays a subset of the system events for audit purposes — security events (such as a failed login) and user actions (such as creation and deletion of a container).

The Events page is visible to users with the IT Admin management policy — who can view all event logs — or to users with the Security Admin management policy — who can view only the Audit tab.

Cluster Support Logs

Users with the IT Admin management policy can collect and download support logs for the platform clusters from the dashboard. Log collection is triggered for a data cluster, but the logs are collected from both the data and application cluster nodes.

You can trigger collection of cluster support-logs from the dashboard in one of two ways; (note that you cannot run multiple collection jobs concurrently):

  • On the Clusters page, open the action menu () for a data cluster in the clusters table (Type = “Data”); then, select the Collect logs menu option.
  • On the Clusters page, select to display the Support Logs tab for a specific data cluster — either by selecting the Support logs option from the cluster’s action menu () or by selecting the data cluster and then selecting the Support Logs tab; then, select Collect Logs from the action toolbar.

You can view the status of all collection jobs and download archive files of the collected logs from the data-cluster’s Support Logs dashboard tab.

API Error Information

The platform APIs return error codes and error and warning messages to help you debug problems with your application. See, for example, the Error Information documentation in the Data-Service Web-API General Structure reference documentation.

See Also